ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Performance Monitoring » SYSTEM.MANAGED.NDURABLE

Post new topic  Reply to topic Goto page 1, 2  Next
 SYSTEM.MANAGED.NDURABLE « View previous topic :: View next topic » 
Author Message
rajeshso
PostPosted: Tue May 13, 2014 1:43 am    Post subject: SYSTEM.MANAGED.NDURABLE Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Hi,

A Managed queue is created when I subscribe for non durable messages. The queue is
SYSTEM.MANAGED.NDURABLE.<arbitrary long number>

The publisher publishes to only one dynamic topic. Lets say X. I don't create a topic. The topic is created and destroyed (I guess) on the fly.

Whenever a subscriber is created for X, a SYSTEM.MANAGED.NDURABLE.<arbitrary long number> is created. When my application publishes few 100s of messages, the CURDEPTH of the SYSTEM.MANAGED.NDURABLE.<arbitrary long number> remains 0 or sometimes a single digit number. There is no problem at all.

I opened a few more subscribers for the same topic, the CURDEPTH of the SYSTEM.MANAGED.NDURABLE.<another arbitrary long number> had a similar behaviour.

When my application pumped 100s of messages per second, the CURDEPTH of the SYSTEM.MANAGED.NDURABLE.<arbitrary long number> increased. The depth of the messages continued to increase and hit the upper limit of the permitted level. If I close the subscriber, the SYSTEM.MANAGED.NDURABLE.<arbitrary long number> gets deleted too. The user does not want to close the subscribers and wants me to solve the problem with Websphere MQ or the code.

What causes the CURDEPTH to increase? As I use a non-durable subscriber, I expect the subscriber to miss the messages, but not persist them. My understanding is that the CURDEPTH should be zero. If it was a durable subscriber, I agree that the depth can increase. But I cannot understand why the NDurable subscriber persists the messages.

Would the problem be in my publisher code or subscriber code or the Websphere MQ setting ?

Your help will be immensely helpful.

Note: The queue can be listed by the following command in runmqsc
Code:

DISPLAY QLOCAL(SYSTEM.MANAGED.NDURABLE.*)

Then take a particular queue and list the following
Code:

DISPLAY QLOCAL(SYSTEM.MANAGED.NDURABLE.<the number you see in the result of the above command>) CURDEPTH

My system displays CURDEPTH(19082). The display for the non-problematic queue is CURDEPTH(0)

Please help

Regards,
Rajesh
Back to top
View user's profile Send private message
rajeshso
PostPosted: Tue May 13, 2014 2:01 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

I am not using clustering or remote queue managers. There is only one queue manager, two topics, publishers are present inside EJBs in Websphere Application severs. The Subscribers are core java programs that listen to either of the topics, display in a JTextArea and log the messages in a file.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue May 13, 2014 3:11 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

You have a connection problem somewhere. The publishing engine is using the queue and the subscribing session is still alive, but the connection between the subscriber and the qmgr is broken.

Have you added a connection listener to your subscribers? What do you do in case of errors?

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
rajeshso
PostPosted: Tue May 13, 2014 6:03 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Hi,
Can this be a problem with acknowledging the messages? Are the messages in the NDurable queue the unacknowledged ones?

I am not doing anything with acknowledgement. I rely on TopicSession's default acknowledgement mode.

Regards,
Rajesh
Back to top
View user's profile Send private message
hughson
PostPosted: Tue May 13, 2014 7:39 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

If you are getting a build up of messages on your SYSTEM.MANAGED.NDURABLE.<arbitrary long number> queue, shown by the CURDEPTH attribute having a big number such as CURDEPTH(19082) this means that your publishing application has sent at least that many messages and the subscriber using that specific queue is not keeping up with retrieving them.

rajeshso wrote:
As I use a non-durable subscriber, I expect the subscriber to miss the messages, but not persist them.

If the subscribing application disconnects from the queue manager then it will miss messages, but while it remains connected they will be stored on the aforementioned queue for the application to retrieve.

If you believe that your subscriber application which is retrieving the messages is not acknowledging the messages after retrieveing them you can check this with the following command:-

Code:
DISPLAY QSTATUS(SYSTEM.MANAGED.NDURABLE.<arbitrary long number>) UNCOM

If the value of UNCOM shows something other than NO, this means you have uncommitted messages on that queue. Acknowledgement is done using a transaction in MQ.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
rajeshso
PostPosted: Tue May 13, 2014 8:31 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Thanks FJP. Thanks Morag.
The subscribers are connected but are hung.

The UNCOM status is as follows
Code:

    43 : DISPLAY QSTATUS(SYSTEM.MANAGED.NDURABLE.*) UNCOM
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B031F0D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(6)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B05650D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B09080D20)
   TYPE(QUEUE)                             CURDEPTH(12229)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B16840D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B16940D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B47010D20)
   TYPE(QUEUE)                             CURDEPTH(12230)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B5A3B0D20)
   TYPE(QUEUE)                             CURDEPTH(12061)
   UNCOM(10001)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B6D7C0D20)
   TYPE(QUEUE)                             CURDEPTH(11526)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B76690D20)
   TYPE(QUEUE)                             CURDEPTH(11696)
   UNCOM(10001)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B81F50C20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(6)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B82260D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(6)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BA3920D20)
   TYPE(QUEUE)                             CURDEPTH(11357)
   UNCOM(10002)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BB3BF0D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BB7F60C20)
   TYPE(QUEUE)                             CURDEPTH(12256)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BE5B90D20)
   TYPE(QUEUE)                             CURDEPTH(11065)
   UNCOM(10002)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BEA5E0D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BF42B0D20)
   TYPE(QUEUE)                             CURDEPTH(12156)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BF5570D20)
   TYPE(QUEUE)                             CURDEPTH(11756)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BF8310D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(5)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B03060D20)
   TYPE(QUEUE)                             CURDEPTH(0)
   UNCOM(6)


At this time, the subscribers have become non-responsive. I think this is the reason that the messages are piled up. I hope I can find out why the subscribers hung. That may solve the problem.

What is connection listener, if I may know ? I could not find such a listener in JMS/J2EE.

Thanks,
Rajesh
Back to top
View user's profile Send private message
hughson
PostPosted: Tue May 13, 2014 9:04 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

rajeshso wrote:
The UNCOM status is as follows
Code:

AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B09080D20)
   TYPE(QUEUE)                             CURDEPTH(12229)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B47010D20)
   TYPE(QUEUE)                             CURDEPTH(12230)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B5A3B0D20)
   TYPE(QUEUE)                             CURDEPTH(12061)
   UNCOM(10001)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B6D7C0D20)
   TYPE(QUEUE)                             CURDEPTH(11526)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0B76690D20)
   TYPE(QUEUE)                             CURDEPTH(11696)
   UNCOM(10001)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BA3920D20)
   TYPE(QUEUE)                             CURDEPTH(11357)
   UNCOM(10002)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BB7F60C20)
   TYPE(QUEUE)                             CURDEPTH(12256)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BE5B90D20)
   TYPE(QUEUE)                             CURDEPTH(11065)
   UNCOM(10002)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BF42B0D20)
   TYPE(QUEUE)                             CURDEPTH(12156)
   UNCOM(10000)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.MANAGED.NDURABLE.53722A0BF5570D20)
   TYPE(QUEUE)                             CURDEPTH(11756)
   UNCOM(10000)


I think you need to sort out your acknowledgments. Also, I suspect you have come up against the limit of Max Uncommitted messages, which defaults to 10000. Issue DIS QMGR MAXUMSGS to check that. But you need to focus on whether you want to acknowledge or not and either do it or turn it off.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Tue May 13, 2014 3:17 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Sorry meant to say ExceptionListener. Got stuck to the fact that you attach it ot a connection...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
rajeshso
PostPosted: Wed May 14, 2014 2:04 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Morag,

Is it possible to switch off acknowledgement ? I am using a J2EE/JMS subscriber that supports Auto Acknowledgement and Dups OK Acknowledgment. Should I turn off Acknowledgment through a MQ setting?

Thanks,
Rajesh
Back to top
View user's profile Send private message
rajeshso
PostPosted: Wed May 14, 2014 5:19 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Hi Morag,

I observed a behaviour on when the subscribers gets hung.

As the publisher pump 1000s of messages/second, the CURDEPTH remains 0 or 1, but UNCOM steadily increases. When UNCOM reaches 10,000, the following two behaviours are noticed.

Firstly, the CURDEPTH begins to increase from 0. The number increases more than 10,000. The UNCOM remains 10,000 or 10,001.

Secondly, the Subscriber that I had written, becomes inactive. The subscriber is connected, but no longer receives messages.

The Acknowledgement mode that I am using is Session.DUPS_OK_ACKNOWLEDGE. I read somewhere this is better for performance than the Session.AUTO_ACKNOWLEDGE.

I don't think the subscribers have generated exceptions. But I will still try FJB's suggestion on ExceptionListener.

Regards,
Raj
Back to top
View user's profile Send private message
rajeshso
PostPosted: Wed May 14, 2014 5:30 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

Hi Morag,
If subscriber doesn't have any code after receiving the messages, there are no problems. So, I suspect the subscribers are not performing to the speed. If the subscribers are not super fast, do you believe I will get into the problem as mentioned where UNCOM increases? As soon as UNCOM reaches 10K, CURDEPTH increase.
I understand my responses indicate I am in a panic mode. I am.
Regards,
Rajesh
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed May 14, 2014 5:54 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

It appears your subscribers are getting the messages under syncpoint. When they do, they can see the data, and apparently take action on it. But they never commit or backout those messages gotten under syncpoint. So the QM has to keep track of them, because the app may decide to rollback or commit them.

Eventually there are 10,000 of these gets under syncpoint and the QM says ENOUGH! You get no more because you have hit the limit of uncommitted messages. And the queue starts to pile up.

Fix the consuming app to commit messages on a regular basis.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed May 14, 2014 6:06 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

PeterPotkay wrote:
Fix the consuming app to commit messages on a regular basis.

Or, fix the app so that it consumes messages NOT in-syncpoint.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
rajeshso
PostPosted: Wed May 14, 2014 6:19 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

I am sorry to contradict my last message. When the subscriber's onMessage() had no code, the behaviour of UNCOMM and CURDEPTH still remained same. The rate of increase in UNCOMM was relatively lesser than when there was code in onMessage().

I don't know why UNCOMM increases when the subscribers are doing the job. I have a belief that if its possible to keep UNCOMM to remain zero, the problem will be solved.
Back to top
View user's profile Send private message
rajeshso
PostPosted: Wed May 14, 2014 6:39 am    Post subject: Reply with quote

Novice

Joined: 13 May 2014
Posts: 10

How to avoid syncpoint? Do I have to set this in the code or a MQ setting? A code based setting will be preferable.

I have not explicitly written code to commit messages. The reason is the JMS supports only two types of acknowledgments. I tried both and both did not have much difference. How do you think JMS subscribers can commit ?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Performance Monitoring » SYSTEM.MANAGED.NDURABLE
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.