EMA JAVA : Batch requests resulting in nameless messages and more time than expected. Is there an...

When you make batch requests, there may be times, depending on the list of items you are requesting, a full length trip through the back-end infrastructure to retrieve data will occur. Subsequent requests will usually be faster because the items are now cached within the ADS.

That being said, taking 2 minutes for a batch of 255 RICs doesn't appear to be right. Please work with your market data team to troubleshoot where the bottleneck could be.

Regarding you Nameless Messages, could you please ask this as a separate question? I would like to separate that from this thread.

thanks @gaurav.mahajan

All comments

@nick.zincone,

Can you please share your thoughts on this? We really need some help from EMA community here as this is blocking one of our real time usecase. Please let me know if i can provide any further information on this.

When you request for a single or batch of items, the request may have to go to the head end to determine validity and to retrieve the item, which is a lengthier trip. In some cases, the data is readily available , (cached) within the direct server (ADS) you are connected into. So you may see responses for some items return immediately and others could take longer, depending how deep the item is within the back end. If you are discovering that requests are timing out, you may need to reach out to your market data team to understand why. When working with some of the market data teams, we have utilized the preload cache feature within ADS where they preload a batch of items within the cache so when requests go out, the items are readily available.

Can you elaborate on what a "nameless message" is? You mentioned you are receiving a number of them.

There is a threshhold on the number of items you can request for. See this post for more details.

@nick.zincone, Thank You very much!

For the issue which we are facing, this does not seem to be the case. If we send one request with around 200 rics using batch subscription, we do not face this issue and response is very fast. But if we send around 200 requests with 40 threads we see that 95% of requests are fine but 1-5 % of requests takes a bit longer due to some of the rics not returned. Can you please throw some light here ?

Nameless message :- When we send batch subscription request we noticed that we also get message for which itemName and state is not set. I was referring to such messages as nameless message.

Because we have no visibility into how you are processing data over 40 threads, it is difficult to nail down why you are experiencing time outs other than perhaps you are not properly processing data efficiently - this will require a much deeper analysis.

That being said, you should consider approaching how you request for data in a much simpler way. Throwing more threads at a problem doesn't necessarily translate into better performance. Having 40 threads requires a significant amount of context switching which can result in slower applications. It's a complicated topic without knowing the nature of your threads and what you are doing. When I work with batches, I always start off with 1 single thread to determine how fast data can come through. I then try to scale up the threads to see if any additional ones can help - in most cases it doesn't. However, depending on your processing and thread usage, the number of cores on your machine etc, there may be additional benefits but you will have to find the "sweet spot" to determine how many.

I'm still unclear as to these nameless messages - are they "Refresh", "Status" or "Update" messages? Can you provide a complete example to better understand?

thanks.

@nick.zincone, I totally agree with your views on Thread processing.

However, another observation which i noticed today it comes sometime with a single thread having a batch subscription of 255 rics also. This looks like the case one consumer used to request data is ideal for some time. But subsequent requests are faster. Again this is also intermittent where we are waiting for some rics out of 255 rics and the response takes around more than 2 minutes for this request. But subsequent requests return within 5-10 seconds.

NameLessMessage :- We are making snapshot subscription. So all the messages are recieved as part of "Refresh" message or "Status" message callback.

Suppose i made a batch request for "RIC1", i will receive a "Status" msg where message does not have any name and msg.hasName will be "false" followed by the expected "RefreshMsg". I am calling them nameless as they do not have name with them. This can be seen with EMA Batch example "example370__MarketPrice__Batch". Please find below code for the same where i was referring : -

public void onRefreshMsg(RefreshMsg refreshMsg, OmmConsumerEvent event)
{
System.out.println("Item Name: " + (refreshMsg.hasName() ? refreshMsg.name() : "<not set>"));
System.out.println("Service Name: " + (refreshMsg.hasServiceName() ? refreshMsg.serviceName() : "<not set>"));

System.out.println("Item State: " + refreshMsg.state());

if (DataType.DataTypes.FIELD_LIST == refreshMsg.payload().dataType())
decode(refreshMsg.payload().fieldList());

System.out.println();
}

public void onStatusMsg(StatusMsg statusMsg, OmmConsumerEvent event)
{
System.out.println("Item Name: " + (statusMsg.hasName() ? statusMsg.name() : "<not set>"));
System.out.println("Service Name: " + (statusMsg.hasServiceName() ? statusMsg.serviceName() : "<not set>"));
if (statusMsg.hasState())
System.out.println("Item State: " +statusMsg.state());

System.out.println();
}

Thanks for your thoughts and please let us know if i can provide any further information.

That being said, taking 2 minutes for a batch of 255 RICs doesn't appear to be right. Please work with your market data team to troubleshoot where the bottleneck could be.

Regarding you Nameless Messages, could you please ask this as a separate question? I would like to separate that from this thread.

thanks @gaurav.mahajan