The only channels involved are the CLUSSDR/CLUSRCVR between cluster members. Applications connect only to the local queue manager.
tonyB. > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Miller, Dennis > Sent: Friday, November 05, 2004 2:18 PM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > I'm confused. Contrary to your claim, there are channels > involved, then????? To further confuse, Amqrmppa may > contribute to OPROCS=4, but I don't believe it contributes to > the IPROCS=12. > > In any case, if I wanted to isolate the process that is > causing the problem, I would shutdown the channels to get > those out of the picture first. > > -----Original Message----- > From: Antony Boggis [mailto:[EMAIL PROTECTED] > Sent: Friday, November 05, 2004 8:37 AM > To: [EMAIL PROTECTED] > Subject: Re: Incorrect CURDEPTH displayed? > > > As some others have pointed out, I should have focused more on the > MQCMIT or as you say, look at the values used in the mqgmo.options > field. Although I have been assured by developers that > they're NOT using > syncpointing, I'm gonna search anyway. > > Of the 12 processes listed at that time, I should have > mentioned that 6 > of them were amqrmppa (the channel pooling process). These stay around > for a while, even after all the local processes are killed. > > tonyB. > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of > > Miller, Dennis > > Sent: Thursday, November 04, 2004 11:19 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Incorrect CURDEPTH displayed? > > > > Let me try to fill in a couple of blanks. First, the conventional > > wisdom would be that recycling the qmgr clears it up > because it forces > > > an end to all UOW's, eliminating all uncommitted gets/puts. > Second, > > client connections are more prone to some unexpected > effects because > > the qmgr is not always intimately aware of the client's state. > > Suppose for example, a client does an MQGET under syncpoint and then > > abends before the commit. In that state you have a queue > > depth 1 greater than the number of messages that you can > > "see" on the queue. That situation remains until the qmgr > > recognizes the client is gone and rolls back the MQGET, which > > might be awhile. Finally, I agree with others that the > > absence of MQBEGINs is not a fair test of whether you are > > using syncpoints. The operative indicator is the use of > > syncpoint on the > > GMO/PMO parameter. > > > > I notice from your display that 12 process have the queue > open when it > > > contains no messages. This suggests a lot of long-running > tasks and > > makes me ever-more suspicious that one of them is misbehaving with > > respect to uncommitted gets/puts. My approach to diagnosis would be > > this. First, see what DISPLAY THREAD shows. If that doesn't reveal > > the culprit, then, terminate the 12 processes one-by-one > and monitor > > the queue depth at each step. If the difference between available > > messages and qdepth changes, then that process is suspect. > > When all's-said-and-done if there are no open handles and > > there is still an inconsistency, then you can throw the > > uncommitted message theory out the window. > > > > Regards, > > Dennis > > > > > > -----Original Message----- > > From: Tony Boggis [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 03, 2004 3:54 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Incorrect CURDEPTH displayed? > > > > > > Recycling the qm does generally clear it up, yes. For a while. I've > > seen this a few times lately. I don't know how a restart is > clearing > > it. No client connections involved (why would that affect things?). > > All apps make direct connections (no channels involved). > > > > Granted that persistence is a message attrib. My error. > > > > Uncommitted gets? Hmmm. Granted that could be a possibility, but in > > our case, as I mentioned, we do not use syncpointing (but > your point > > about using syncpointing is interesting). A grep on all source code > > finds not > > one instance of MQBEGIN. > > > > tonyB. > > > > > -------- Original Message -------- > > > Subject: Re: Incorrect CURDEPTH displayed? > > > From: "Miller, Dennis" <[EMAIL PROTECTED]> > > > Date: Wed, November 03, 2004 2:27 pm > > > To: [EMAIL PROTECTED] > > > > > > Does recycling the QMgr clear it up? > > > And, if so, how--by restoring the messages or by clearing > > the qdepth? > > > Are any applications using client connections? > > > > > > > > > You said> > > > The queues are set as non-persistent. > > > > > > >>Persistence is a property of a message, not a queue. > Any queue can > > > hold persistent messages. > > > > > > > > > You said> > > > We do not use units-of-work (no Begin/End). > > > > > > >>My-oh-my. There's a fair chance that uncommitted gets are the > > > culprit. I have never heard a defensible argument for doing gets > > > outside of syncpoint. Problems like phantom messages and dropped > > > messages are an expected result. > > > > > > > > > Regards, > > > Dennis > > > > > > > > > -----Original Message----- > > > From: Tony Boggis [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, November 03, 2004 12:45 PM > > > To: [EMAIL PROTECTED] > > > Subject: Incorrect CURDEPTH displayed? > > > > > > > > > I have a queue manager that is showing a current depth > > (non-zero) on > > > several application queues. However, when I browse the queues > > > (MQExplorer or amqsbcg) I get nothing. Also, when I browse > > the queues, > > > > > the count does not go down to zero (as I might expect if > there were > > > expired messages). > > > > > > The queues are set as non-persistent. > > > We do not use units-of-work (no Begin/End). > > > We do not set expiry time on messages. > > > > > > Apart from this "ghost" depth, everything seems ok. I can get/put > > > messages as normal. I just can't seem to get curdepth to > return to > > > zero. > > > > > > Suggestions? Am I missing something obvious? > > > > > > This is on Solaris 5.8 with WMQ 5.3, CSD08. > > > > > > tonyB. > > > > > > Instructions for managing your mailing list subscription > > are provided > > > in the Listserv General Users Guide available at > > http://www.lsoft.com > > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > > > Instructions for managing your mailing list subscription > > are provided > > > in the Listserv General Users Guide available at > > http://www.lsoft.com > > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > Instructions for managing your mailing list subscription > are provided > > in the Listserv General Users Guide available at > http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > Instructions for managing your mailing list subscription > are provided > > in the Listserv General Users Guide available at > http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > Instructions for managing your mailing list subscription are > provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list subscription are > provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
