Hi @niz

There is not necessarily one right way of doing this. It's about doing what works best for your requirement - within the guidelines provided.

If you feel the cleanest / easiest to manage implementation is to create a separate OmmConsumerClient instance for each user's requests then that should be OK - just test to satisfy yourself this approach will provide a robust and stable solution in production when the number of users is high.

In terms of using multiple OmmConsumer instances - as I have mentioned previously there is considerable overhead for each OmmConsumer e.g. login, directory, dictionary etc - so it would be better to keep these to a minimum. However, you may find you need to use a few instances depending on the number of users and requests etc - in order to spread the load between more than one instance - as each instance will have its own threads etc.

Also, each OmmConsumer can connect to a different server(ideally ChannelSet) for further spreading of the load if required.

The key thing is using the Open DACs API to authenticate each user and check their entitlements before serving them with any data. Failure to do so would put you in breach of the data providers requirements and potential audit failure.

Another general recommendation is to use ChannelSets rather than a single named server for each connection - this allows the API to try and recover from server loss scenario by automatically trying an alternative server if one goes down.

Hi @niz

From your description, it would appear that you need to implement proxy permissioning.

In other words, you would use a single functional DACS ID for your OmmConsumer to login to the server + request the data required by the various users.

You would then use OpenDACS API to perform authentication (i.e. are they a valid user?) and entitlement (are they permissioned for the instrument they are requesting?) - before providing any data to the downstream user.

I have included a few links below on the OpenDACS API

Introduction to the DACS Entitlement System for OpenDACS Developers

Open DACS API landing page + links to tutorials etc

Also, the forum question below has some examples for using OpenDACs with EMA C++ and EMA Java

previous forum question with examples for using OpenDACS with Elektron Message API

• Is then the assumption that for for each request a client is needed, and with that i would need to register a log in client and hold its handle and unregister it when closing all.And for each client that will register a batchview request get the handle from every update if I decide to close a specific instrument? And the parent handle if i would like to close the parent client? Though documentation says that the batch view is closed after it returns then each item has its own stream, is that stream the handle?

Hi @niz

Apologies if I misunderstand some of your questions but I will try and answer them...

You can use the same client instance with as registerClient calls as you like. Developers only generally use different client definitions where they represent different processing when dealing with different asset classes, different sets of fields etc and they then create one instance of each client definition for each all rics corresponding to a partcular asset class/field set etc to make processing the different data simpler.

Many developers use a single instance and definition to deal with all their RICs - it is an implementation choice. However, it is quite rare to use multiple client instances - one for each request etc - and not something we would recommend.

The handle and stream ID are two different things

You should only need to login once using the functional Dacs Username. Closing the login handle logs you out from the server so is not something you would normally during the runtime of an application - it is usually for a cleanup/shutdown type scenario.

The handle can be obtained from the OmmConsumerEvent passed to the onRefresh, onUpdate, OnStatus msg handlers

public void onRefreshMsg(RefreshMsg refreshMsg, OmmConsumerEvent event){         System.out.println("Received Refresh. Item Handle: " + event.handle() + " Closure: " + event.closure()); 

So, you would use the handle for a specific subscription to unregister and close its corresponding event stream.

In terms of a batch request - you make a single request, but as a result, the server opens up multiple streams - one for each valid request and each stream has its own handle (and id). The batch request is closed off as it has fulfilled its purpose.

I personally don't use Batch requests, IMHO they add additional complication for not much benefit - I just request each instrument individually in a loop - with some throttling/pacing of requests.

In terms of identifying individual item stream in order to close etc, you can also use the Closure parameter to pass in your own unique Identifier as part of the registerClient call, and then extract the Closure value in the OnRefresh, OnUpdate msg handlers

registerClient(ReqMsg reqMsg, OmmConsumerClient client, java.lang.Object closure) 

As you will note, close is of type Object so you are free to pass in whatever you want to use

If I have misunderstood any particular question please expand / rephrase or even post as a new question on the forum for clarity purposes.

The scenario is mostly for streaming data.and there are multiple end users issuing multiple requests hence and each request for the user could be from a different source hence a consumer could be reused but not the client that will actually be handling the updates and the user would mostly come with a large list of instruments

Hence how to split these separate requests if not by clients

Flow such as

1. create consumer
2. register login client
3. register client with batch view (provide closure x) for instruments a,b,c
4. new request, get exiting consumer
5. register new batch view client (provide closure y) for instruments x,yz

would this flow be correct knowing that each request is independent from each other