Hi!

I’ve put together two custom java service on my Integration Server (version 9.12) that basically follows the sample code provided in the Universal Messaging Developer Guide for Queue browsing / peeking. These services initially worked fine when both doing a count of messages in the queue matching a provided selector string (e.g. a customerId or similar) and also fetching the publish time of the first message in the queue. At some point in time both these services have stopped working. No exception is thrown and no events are found even though there are messages on the queue.

The following line of code is expected to find the events: nConsumeEvent evts = reader.peek(ctx); (as per documentation).

I have tried to remove the message selector part of the of the nQueuePeekContext constructor, but I’m stil not able to find any messages on the queue.

Any ideas on what could be causing this issue?

Regards,
Håkan

Hi Hakan,
Can you tell me what fix level your IS and UM 9.12 are at?
Thanks, Jane.

Thanks for a quick response.
It looks like the following fixes are applied.

IS:
IS_9.12_Core_Fix8
TNS_9.12_Fix4
IS_9.12_SPM_Fix2

UM:
Java Client 9.12 Fix 7
JavaScript Client 9.12 Fix 3
C++ Client 9.12 Fix 6 (LNXAMD64)
Enterprise Manager 9.12 Fix 7
Realm Server 9.12 Fix 7
Migration Utility 9.12 Fix 1
Template Applications 9.12 Fix 7 (LNXAMD64)

Update: A related thing is that the snoop functionality within Enterprise Manager has also stopped working for the specifiq queue that I’m working with. I don’t know if this is related to the same root cause in this case, but other queues can be snooped. I can’t find any obvious issues in EM with e.g. massive amounts of sessions (that could have been created from the service).

Hi,

This seems unusual. How are you verifying that there are events on the channel? Are you aware of any change which may have been correlated with when the behaviour changed?

Regards,

Stuart

Hi Stuart!

Yes there are messages on the queue. I can verify that both via EM or by running a simple java service (not using peeking functionality, but rater getting queue details):

nSessionAttributes nsa = new nSessionAttributes([realm connection details]);
mySession=nSessionFactory.create(nsa);
mySession.init();
nChannelAttributes cattrib = new nChannelAttributes();
cattrib.setName([queue path]);
nQueue myQueue=mySession.findQueue(cattrib);
nQueueDetails nqd = myQueue.getDetails();
count=nqd.getNoOfEvents();

So this problem seems to be specific to the peeking/browsing part of the UM API.

Hi Håkan,

That’s strange. Support should be able to investigate this. It may be helpful if you are in a position to send the queue’s .mem file. This would probably be required to reproduce the issue since a queue getting into this state seems very unusual.

Has the behaviour persisted over server restarts?

Stuart

Hi!

We have restarted both IS and UM to see if that would help, but that problem remains. So we will probably need to involve the support team in order to get any further with this.

//Håkan

If you have the .mem files backup for the queue, you can try restoring them and restart UMS. If not, recreate the queue. I have noticed issues with the .mem files when there is no free disk space on UMS installed server.

Hi!

Just a bit of an update regarding this topic in order to provide details for future readers.

We decided to not pursue any support help in order to resolve this issue with the unresponsive queue - explicitly related to queue browsing/peeking. The queue was instead recreated which resolved the problem. We might however have found a potential causes. When digging into the java documentation I found that the valid input for the following call: nQueueReader.createContext(int, String), must provide a positive integer value. When building the initial versions of the java service I would test the service using the input ‘-1’. The service still worked with this input (at least for a while) but might be a reason as I don’t know what could happened when peeking the queue with the infinite window size.

Thanks for all the input on this topic!
Regards,
Håkan

Thank for the update and it is indeed very helpful for the future readers!!

Cheers!
RMG