The flow of our application is:
The problem we are seeing is that the connection is not closed. Every time the app runs it creates a new connection. This is causing high CPU load and memory leak.
Can you confirm which version of the EMA Java API you are using? The latest version of 1.5.0.L1 is available here.
Also, are you able to recreate by taking one of our basic examples and making minimal modifications to implement the above usage scenario?
In addition to the above, the key thing I should point out is that the above usage scenario is far from optimal.
When you create an OmmConsumer and pass the config etc, there is a lot of background process taking place e.g. connect + login to server, download directory of services, download dictionary (or load local) etc - all of which takes time and places a potentially unnecessary burden on your resources.
The recommended approach would be to create the OmmConsumer once and continue to use that same instance to consume data as often and whenever required.
Note that if you are making Snapshot request i.e.RefreshMsg only and not interested in Updates, then you can use Snapshot mode - so that the API unregisters each instrument for you automatically once it has responded with the RefreshMsg (or closed StatusMsg for invalid requests).
consumer.registerClient(reqMsg.serviceName("DIRECT_FEED").name("IBM.N")
.interestAfterRefresh(false), appClient);
However, if your particular implementation requires you to create, register and uninitialize then please respond with a simple application which demonstrates your implementation and the problem - so we can recreate and report to the development as appropriate.
what will be the case for DACS enabled servies, the OmmConsumer is created with the DACS user name, for a different user a different OmmConsumer instance is created as the username is passed to the connection config, if we have a long running process or application that is serving multiple users the issue with the connection kept open will result in memory leak andconsumers being stuck in memory, and only become dirty when the java application exits.
And this is the case when we have batch-view for multiple instruments and an open stream.
Then for each OmmConsumer a Login handle is needed to mapped and stored with the consumer and when no clients are retrieveing stream, unregister the login handle
And also manage the stream update handle to close the individual streams that end up being created by the batch view.
