question

Upvotes
Accepted
65 2 3 10

OmmConsumerClient Registration Count Recommendation

Within a consumer application, should a single OmmConsumerClient instance be used to handle all OmmConsumer::registerClient() for every single item the application will register for?

Or is there a recommendation to split this up to multiple instances of OmmConsumerClient?

ema-apiommconsumer
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvote
Accepted
17.9k 82 39 63

Hi @mzmuda33

A single OmmConsumerClient instance is usually sufficient to handle your subscription requirements. That being said, it entirely depends on your application and the machine you intend to run your application. If you are running an application that handles thousands of subscriptions and the post-processing within the callbacks is consuming a significant amount of CPU, the application can potentially suffer from a "slow consumer" scenario where the internal dispatching cannot keep up with the volume of data coming down your connection. Applications do have the ability to control dispatching by choosing an alternate operation model. See the discussion within section 2.4 Product Architecture within the Developer's Guide.

In the situation where your machine contains multiple cores and your application would like to take advantage of them, you can refer to the Horizontal Scaling example.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
22.7k 59 14 21

Hi @mzmuda33, this will really depend on your application architecture, but for a majority of the apps which extract data from refresh/update message and immediately relinquish the callback thread, a single instance of client would be work fine.


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks @Gurpreet . In my case, I will have many items registered with interest (dozens, maybe even hundreds) that will be open streams to receive updates, possibly pausing lower volume items at some points in time.
Yes, that should work fine - the trick is not to hold the callback thread. If some time intensive processing is required, then copy the data into memory and have your application threads work on that data.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.