Author |
Message
|
RangaKovela |
Posted: Wed May 20, 2015 7:32 am Post subject: - Durable Subscribers disappeared from MQ |
|
|
Apprentice
Joined: 10 May 2011 Posts: 38
|
Hi Experts,
We had Linux upgrade recently on our servers and post upgrade followed by restart of qmgr we found all durable subscribers were lost.
All these subscribers were created by Application (SUBTYPE(API))
dis sub(*) all - returns nothing..
Upon further investigation, we found that
When we were backing up qmgr using MS03 Saveqmgr, SYSTEM.DURABLE.SUBSCRIBER.QUEUE curdepth was zero. We were able discover this in saveqmgr o/p.
DEFINE QLOCAL ('SYSTEM.DURABLE.SUBSCRIBER.QUEUE') +
* CRDATE (2013-01-09) +
* CRTIME (09.10.26) +
* ALTDATE (2013-08-26) +
* ALTTIME (08.35.21) +
DESCR('Store of information about durable subscribers') +
PUT(ENABLED) +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFPRESP(SYNC) +
* CURDEPTH(0) +
However same saveqmgr o/p shows some subscriber definitions.
After qmgr restart, these Subsciber definitions were lost. I am suspecting that this could be because QMGR was unable replay subscriber definitions as SYSTEM.DURABLE.SUBSCRIBER.QUEUE was empty.
We want to understand possibilities of clearing SYSTEM.DURABLE.SUBSCRIBER.QUEUE
As per manual DURABLE subscribers are lost if and only if application calls un-subscribe method ..
Quote: |
"an application calls the Unsubscribe method of a Session object, specifying as a parameter the name that identifies the durable subscription. The client identifier associated with the session must be the same as that associated with the durable subscription. The messaging server deletes the record of the durable subscription that it is maintaining and does not send any more messages to the durable subscriber" |
We are sure that none of the MQ Admins had cleared SYSTEM.DURABLE.SUBSCRIBER.QUEUE queue..
Could you please throw some light on this issue and share your thoughts on this? |
|
Back to top |
|
 |
mqjeff |
Posted: Wed May 20, 2015 7:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Nothing would have cleared the queue.
The reapplication of the saveqmgr config might have replaced the queue.
You should be, in general, careful of reapplying system object definitions.
Your admins could have also done strmqm -c. |
|
Back to top |
|
 |
RangaKovela |
Posted: Thu May 21, 2015 3:10 am Post subject: |
|
|
Apprentice
Joined: 10 May 2011 Posts: 38
|
strmqm -c or reapplying saveqmgr config was not done. In fact, qmgr started with reboot of server using auto start scripts configured in /etc/init.d.
Qmgr started without any issues.. no fdc or error observed. |
|
Back to top |
|
 |
Andyh |
Posted: Thu May 21, 2015 4:20 am Post subject: |
|
|
Master
Joined: 29 Jul 2010 Posts: 239
|
If the system.durable.subscriber.queue had been cleared during the migration (which should NEVER happen), it would still be expected to have been populated after the migration with the queue managers internal subscriptions.
Hence it seems likely that the queue was 'cleared' AFTER the queue manager restart.
The observation that the depth of this queue was zero in the saveqmgr output then suggests that the queue was emptied both before AND after the restart, hence it seems likely that some 'application' is removing the messages from this queue ?
Are you sure that none of your programmers could have mistaken the purpose of SYSTEM.DURABLE.SUBSCRIBER.QUEUE and tried to consume messages from that queue ?
I'd suggest that when you create a new durable subscription with MQ trace active, then check that SYSTEM.DURABLE.SUBSCRIBER.QUEUE is non empty and remains non empty. If that queue becomes empty while the trace is active it should be pretty easy to see who removed the message. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu May 21, 2015 6:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Andyh wrote: |
Hence it seems likely that the queue was 'cleared' AFTER the queue manager restart. |
Again, I think a DEF QLOCAL(...) REPLACE will do that, and has to occur when the queue manager is running.
saveqmgr is perfectly capable of creating commands with REPLACE in them. |
|
Back to top |
|
 |
Andyh |
Posted: Thu May 21, 2015 10:32 am Post subject: |
|
|
Master
Joined: 29 Jul 2010 Posts: 239
|
Updating the queue definition (Define + REPLACE) does not cause the messages to be removed from the queue.
If this was done operationally then you'd be looking for a runmqsc CLEAR command (or PCF equivalent).
Given that it appears the issue has repeated it seems more likely that the messages were erroneously removed using MQGET. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu May 21, 2015 10:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Andyh wrote: |
Updating the queue definition (Define + REPLACE) does not cause the messages to be removed from the queue. |
 |
|
Back to top |
|
 |
RangaKovela |
Posted: Fri May 22, 2015 12:36 am Post subject: |
|
|
Apprentice
Joined: 10 May 2011 Posts: 38
|
I am trying my luck Omegamon monitoring .. thanks for your help |
|
Back to top |
|
 |
samsansam |
Posted: Fri May 29, 2015 10:06 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
I might be wrong , but I believe when you restart QMGR, queues with DEFPSIST(NO)
will lose all message , and queues with DEFPSIST(Yes) will not lose messages.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri May 29, 2015 10:54 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
samsansam wrote: |
I might be wrong , but I believe when you restart QMGR, queues with DEFPSIST(NO)
will lose all message , and queues with DEFPSIST(Yes) will not lose messages.  |
This is a common misconception.
Queues have no persistence, messages do. The defpsist attribute of the queue is the persistence of the message put to the queue with the flag persistence as queue definition set.
So no the persistence attribute of the queue has nothing to do whether or not messages survive a queue manager restart. The persitence attribute of the message itself will decide that...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat May 30, 2015 3:51 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
samsansam wrote: |
I might be wrong , but I believe when you restart QMGR, queues with DEFPSIST(NO)
will lose all message , and queues with DEFPSIST(Yes) will not lose messages.  |
Do you mean mpmclass(high) queue attribute? _________________ 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 |
|
 |
|