I have a java service that returns the number of current events for a given channel in UM. I can see the number during debug mode but when running the service, the output data always resulted in 0. What I’m seeing here is that any nLeafNode functions that returns long value, the pipeline output is always 0. If I use a different nLeafNode function that return a string, then I can see the value correctly. Anyone else experiencing this symptom or is there some sort of a bug within Eclipse IDE.

nLeafNode leaf = null;
long currentEvents = leaf.getCurrentNumberOfEvents();

String outStr = Long.toString(numEvents);

Hey,

I’m not aware of such an issue in Eclipse, however this particular method that you mention is getting statistical information from the leaf node, and that data is received asynchronously by the administrative session, so if you have just created that nRealmNode, it might be the case that it has not received its first update just yet.
Once an administrative session is open, it will receive these asynchronous updates from the server on regular intervals. Most of the time when you query for some information, the session won’t call the server explicitly, but rather it’ll just give you the last info it has.
Administrative sessions are generally quite expensive to just open one in order to extract one of these statistics, and then recycle it afterwards. It is usually a better approach to keep one open and use it to get the info you are after.

Thanks,
Stefan

It could be possible due to a bug in your implementation of the java service. Can you provide your java service code?

Add a sleep of 10 seconds before getting the number of events. The reason for this delay is async update as outlined in Stefan’s comment.

Thanks Stefan. Your response is very interesting and news to me. Is there a better approach on capturing the current channel events as it’s requested by our team to develop a automated alert mechanism. Basically, what we are trying to achieve is alert when the channel events start piling up and get notified on it. Wonder if this can be easily achieve via Command Central. I think monitoring the queue depth vs the channel depth would be less expensive based on your comments.

It’s not Bhaskar Reddy Byreddy. I’ve already provided the code snippet. I think Stefan response might explain the behaviour that I’m seeing.

Stefan,

You mentioned that “quite expensive” to open one. I’m planning on using this new service that I created as part of a framework to monitor the UM channels. Therefore, this service will probably be executed on a schedule. When you say “better approach to keep one open…”, what do you implying? You have an example?

That worked Sandeep.

Thank you Sandeep and Stefan as I’m sure this will helped several others as well!

Hello Phillip,

Yes, it is somewhat expensive, because the nRealmNode will try to create a complete view of the server on the client side, all the configuration, assets (topics, queues, data groups), metadata of these assets and then statistical information about them. Furthermore, if this realm server is part of a cluster, a zone, or has a connection to another realm server, this same administrative session will also follow that link and will similarly build a complete picture of the other server as well, and it will proceed the same way until it’s traversed the entire landscape. This will happen regardless of whether you request any of this information from the administrative session or not.

Therefore the administrative session is better utilized as a long-living object, e.g. create one in the beginning of the life cycle of your application, keep a reference to it, and keep it alive until the end of life of your app. You can still have your scheduled poller obtain information from the session on a regular interval.

Cheers,
Stefan

Thanks Stefan. So what you’re saying is have a service to persist the nRealmNode session persisted in memory and this will always be available as long as the IS server is running. Have another service to reference the nRealmNode object session and grab whatever information is needed.

Thanks for your contribution to the community.

Hi Stefan,

I’m assuming to persist the nRealmNode object into memory is done by Serialization vs Properties object right?

Example 1:

ObjectOutputStream out = new ObjectOutputStream(file);

// Method for serialization of object
out.writeObject(object);

Example 2:

Properties properties = new Properties();
//TODO: Logic to get InputStream

properties.load(stream);

Hi,
Stefan’s suggestion is not about the serializing the object.

What you need to do is following

1. Create 3 java services in the same folder
2. First Java service creates the nRealmNode node and assigns it to a static field defined in the java class representing these java services
3. Second service fetches the channel depth or any property from the nRealmNode instance created by the first one
4. Third service destroys the nRealmNode instance created by the first one
5. Register the first service as a startup service of the containing IS Package
6. Register the third service as a shutdown service of the containing IS Package

Hope this helps.

Regards,
Bhaskar.

Byreddy,

I understand exactly what Stefan is suggesting. I was more looking the detail on loading the nRealmNode object into memory. Everything else, I’ve already well aware.

Wondering if this still works considering the data are not static.

ByReddy, do you have an example of #2. I’m still questioning whether this will work considering these data are not static.

I must say I’m not well familiar with IS and how you can achieve that thing there. Storing the session in a static field somewhere will probably work - just make sure you don’t leak it.

On your other question, if you just need the number of events on a channel/queue, you should be able to retrieve that information through the client API as well. It should be something like:

nSession session = nSessionFactory.create(…);
nChannel channel = session.findChannel(…);
channel.getEventCount();

or

nQueue queue = session.findQueue(…);
queue.getDetails().getNoOfEvents();

Both of these will send a request to the server and retrieve the current state of the channel/queue - effectively in a real synchronous poller fashion.

Cheers,
Stefan

You should obviously init that session…

session.init();

Thanks Stefan. We would prefer to use the more synchronous approach vs asyn. Definitely nRealmNode will not be used for our purpose. I did try the synchronous route earlier but didn’t understand why I was always getting zero as the result. I was using the wrong method (ugh).