View number of messages not consumed

, ,
1

Little background story: we have a processing service that sometimes will hang (network connectivity pb). This cause the IS trigger to ‘wait’ and not consume any other document (until a restart)

One workaround was to increase the number of threads so even if one ‘hangs’ the others will keep processing documents.
This is of course not a final solution.

But in the meantime we want to be able to identify the problem. One easy way to monitor our triggers with the Broker was to check the number of documents in the queue.

But I cannot find a way to monitor UM to know the number of documents not consumed (we know they are pilling up somewhere, because when we restart the trigger, they all get processed).

Any advice on how we can do that ? can do it by physically monitoring UM’s files ?

any advice will help,

Thanks !

2

Jonathan,

we introduced that capability in UM 9.9. In Enterprise Manager, you can click on a channel (linked to an IS doc type or JMS topic), then go to Named Objects and see the number of outstanding messages for that trigger.
The same information is also accessible using the UM Admin API.

In UM 9.12 we made it even easier, with visibility in Command Central. In Command Central there is now a single table view of all durable subscribers where you can see the number of outstanding messages for all triggers in one place. You can even sort the table to bring any stuck triggers to the top.
This information can also be accessed using the Command Central CLI or REST API.

For earlier versions, the only way to figure out the backlog is indirectly by looking at the last Event ID on the durable subscriber and comparing it with the last event ID on the channel. The bigger the gap, the bigger the backlog.

Hope this helps.

1 Like
3

Thanks for the reply!
As we are on 9.8, I’ll look into the lastEvenID checks.
It is sad it was sold to us as ‘a better broker’. Version 9.8 is not.

Thanks again

4

Jonathan, do you know the impact of having UM version 9.12 installed in a 9.8 environment ? (all other products version 9.8 )

Thanks

5

Jonathan,
first, you would need to install UM 9.12 in a different installation directory (or different machine) from the 9.8 products.
You would also need to manually copy the UM client jars (nClient.jar, nJMS.jar, nAdminAPI.jar) from common/lib in the UM 9.12 installation to common/lib in the 9.8 installation. You will also need to be careful to NOT accidentally install an UM 9.8 client fixes in your 9.8 installations, as they would overwrite the manually copied jars.
This combination should work fine, but is not officially tested or supported and it will only work for IS connecting to UM. We do support the combination of IS 9.8 with UM 9.9, which might help.

1 Like
6

Thanks again for the reply,

regarding the workaround you mentionned ; I managed to find the channel’ last Event ID, but i cannot find the durable subscriber’s one.
As we come from the ‘broker’ we do not use JMS triggers, but webm triggers.
Is it possible to do with the native webm triggers ?

Thanks

7

Hi Jonathan,

Thanks for the info on how to view the queue size for Topics.

Do you know how I can do the same thing for a Queue? Given there is no durable subscriber, I cannot use the same technique.

This is for v9.9

Can Command Central do this?

Thanks,

Steve

8

For queues it is a lot easier. In Enterprise Manager you can simply see the queue stats which show the number of events. Look on the Status tab at the Events number at the bottom-right in the Event Store box.
This is available in all UM versions.

9

We have a requirement where the messages are sent to the Topics in UM but there are no consumers defined. So in such cases can some one please help us to have the topic flushed without messages getting piled up. Is there a concept of volatile documents in UM as in broker. Thank you.

10

Suneetha,
if you have a Topic (= UM channel) that is defined with the JMS engine (which is default if you create the topic from the JNDI tab), then you won’t get messages piling up if there are no subscribers defined. If your subscribers use durable subscriptions (DS), then messages will indeed pile up while the subscribers are offline. If you know such a subscriber is not coming back, then you can remove the durable subscription using Enterprise Manager by going to the Named Objects tab for the channel, clicking Get Names, selecting the DS you want to remove and then clicking Delete.
All of this has nothing to do with volatile messages. UM does have such a concept (called Non Persistent), but that does not prevent things piling up if you have things configured wrong. The only difference is that non-persistent messages pile up in memory and are lost when UM is restarted, while persistent messages pile up on disk and do survive a restart.

Hope this helps.

11

Thanks Heywood , providing your inputs…

i have one concerns on topic.

If TTL or capacity is set - the messages get deleted once the limit is reached - irrespective of whether the messages are consumed or not.

I would like to keep the messages in queue until they are consumed and delete once they are acknowledged.

12

If you set TTL and capacity to zero, then both are effectively unlimited and messages won’t be removed until consumed or explicitly purged.
Note that with topics, you need to use Durable Subscribers to ensure messages continue to be queued, even while the consumeri s disconnected.

1 Like
13

Thank Jonathan for your info…

It is regarding Non Durable Subscriber, I want to know whether messages will be removed automatically from topic if no consumer is connected.

Please confirm my understanding, If we use Non Durable Subscriber then we cannot re publish the messages whenever we required (In topic if we select channel type as Mixed) and if we restart UM then we may loose messages from topic.

Also, Do we get any acknowledgement when data is consumed or Not consumed and where we can see these details.

14

If you have a non-durable subscriber and you use the JMS engiine (property of the UM channel), then any messages published while the subscriber is disconnected will be discarded. If you want to ensure they are stored in UM and delivered when the subscriber comes back online, then you should use a Durable Subscriber. That is what Durable Subscribers are designed for.
If you use the Default engine for the channel, then messages will be stored on the channel until purged, either explicitly or through TTL or capacity settings. This is irrespective of subscribers having received the messages.
Whether messages stored on the UM server survive a server restart, is determined by the channel type. If the channel is Persistent, or it is Mixed and messages are sent as Persistent, then messages are stored on disk and will still be there after a server restart.

From your questions, it sounds like you should be using Durable Subscribers in combination with persistent messages over a Mixed channel. That will ensure that messages are stored while a subscriber is offline and will be guaranteed to reach the subscriber eventually, even after UM server restart. This is a very common pattern and doesn’t require extra coding, resubmission, ack checking, etc.

1 Like
15

Thank you very much your info…

we were using Non-Durable subscribes in combination with Mixes channel. would you like let us know, what happened in this scenario.

Also how to get any acknowledgement. when data is consumed or Not consumed and where we can see these details in MWS or UM logs.

16

If you use non-druable subscribers with a mixed channel, then the behavior is as follows:

  • If you have JMS engine enabled, then messages are passed to active subscribers when they are published. If a subscriber is offline when a message is published, then the message is discarded and there is no record of it having existed.
  • If you use the Default engine, then messages are passed to active subscribers and are stored on the channel. If an inactive subscriber comes online then they will get ALL the messages on the channel, including those published in the past. Messages must be explicitly purged, or set to purge using TTL or capacity settings.

As you are using a Mixed channel, the way messages are stored depends on the DeliveryMode header property. If you set this to PERSISTENT (default for pub.jms:send from IS), then they are stored on disk and will survive a restart. Otherwise they are stored in memory and will be lost if UM is restarted.

Generally you cannot see anywhere when messages have been consumed if using non-durable subscribers. If you use durable subscribers, then the more recent versions of UM will allow you to see exactly how many messages are waiting for each subscriber.

Is there a reason you are not using Durable Subscribers?

1 Like
17

Thanks Jonathan for explain durable and non-durable step by step info…

We were using 5 subscribes and 4 consumers message are subscribe and 1 consumer is not yet subscribe. in this scenario how to identified which one is not yet consume to subscribe whether will check for logs
which one not yet subscribe…

Could you please explain above scenario…

18

I’m sorry but I don’t understand your question.
When you say you have 5 subscribers and 1 is not yet subscribed, what do you mean? Do you mean that the 5th subscriber is not yet running?

19

Hi Jonathan,

Thanks for the response.

Suppose We have 5 Subscribers on Target Side. We have published the data. Unfortunately one Subscriber is down. So 4 Subscribers have subscribed the data. How we would know which subscriber has not received the data. Do we get any acknowledgement from UM regarding which subscriber has subscribed the data.

20

If you use non-durable subscribers, then you cannot find out which subscribers did and which didn’t receive the message. UM does not keep that information.
As mentioned before, in your use-case you really should be using durable subscribers. They will ensure that all subscribers eventually receive every message, regardless of whether they are down when the message is published.
Is there a reason that you don’t want to use durable subscribers?