New posts are disabled while we improve the user experience.
You can browse the site, or for urgent issues, raise a query at MyAccount.
Hi,
I notice that the OMMMsg being received as part of the updates, most of then than not, seem to have same hashcode even though their attributes indicate that belong to different RICS. In my case I subscribe to a couple of RICS in the same DDS and I notice that 50-70% of the time the OMMMsg's hashcodes are the same for the updates.
OMMMsg msg = event.getMsg();
Is this an intended behavior? How do we get around this?
Thanks.
Regards,
Ganesh
Hello @ganesh.shivshankar
As you will need a deep copy for what you are doing, OMMPool.acquireCopy(OMMData) is not suitable and I suggest you use the OMMMsg.initFrom(OMMMsg) but do keep in mind that if/when you release these objects back to the OMMPool they will re-appear with the same hashCode when they are re-used.
Hi @ganesh.shivshankar. The OMMMsg above is owned (created, managed and released) by the RFA API and API can reuse the same container to pass on different messages to the application. This is done to optimize memory management - which is why you are getting same hash for multiple updates.
To distinguish between updates from different subscriptions, the app can:
Thanks for the quick response! This is causing problems for us as we are trying to hold the incoming OMMMsgs in a queue and process the messages in a separate queue altogether (so as to not block the rfa thread as we have highly volatile RICs being subscribed to). So it results in objects being overridden one for the other. So we have resorted to do a deep copy of the OMMMsg using initFrom and put that into our queue, but we are not sure of the implications of doing this. Is this recommended?
The event queue dispatch thread is owned and controlled by the user application. So RFA thread will not be blocked, when the user is processing the events.
The memory impact of holding the object in RFA event queue vs. deep copying will be same. If the application does not process messages fast enough, it will eventually run out of heap memory.
Hello @ganesh.shivshankar
As the hashCode() method is supported for the benefit of hash tables you should note that the objects passed to the the Client interface by the API belong to the API, they will be reclaimed when the processEvent method has returned and potentially recycled by the API (The exception to this rule is the closure argument). Therefore you should not attempt to store these objects.
The closure argument is supplied by your application when you register the client and is contained in any event received as a result of registering that client interest - could this satisfy your requirement?
The closure (we have this in place already) does give us a context for the incoming message, but we have a some business logic to perform on the messages as they arrive, which is slightly processing intensive and could block the event queue thread and hence we want to defer that to a different thread. Would storing the payload (msg.getPayload()) from the message in a queue help in this case, instead of storing the entire OMMMsg object? I see that the hashcode of the payload is always different.
If you do not need the entire image you should find it more efficient to copy out the fields you require (assuming MP model) and potentially reduce the workload further by using views.
We do filter out what we need using views, but we still need to defer the parsing of the payload to a different thread, in order to avoid blocking the event queue. We use the OMM model. So would storing the payload (OMMData) work here or is that not recommended either?
