Author |
Message
|
jefflowrey |
Posted: Mon Jan 08, 2007 5:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
amqsputc may not be putting persistent messages. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jan 08, 2007 6:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sroach76 wrote: |
But when I add this message manually with the amqsputc command I do not see the /var/mqm/qmgr/NAME/queues/TEST/q file change at all. The file size does not change and I do not see any difference in the q file. Is there somewhere else where the actual message is stored that I am missing or is this the main problem with trying to do file replication of MQ? |
The file size may not change - space allocation is handled internally by the queue manager. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
wschutz |
Posted: Mon Jan 08, 2007 6:42 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
sroach76 wrote: |
Thanks for the tips. I was finally able to put and get a message on the server. I think it was an issue with the '!' I tried another queue named TEST and everything worked fine.
I hear what you are saying about file replication probably won't work but I want to test it just so I can be sure. I have tried putting a message in the TEST queue on the primary server and am replication the entire /var/mqm filesystem. But when I add this message manually with the amqsputc command I do not see the /var/mqm/qmgr/NAME/queues/TEST/q file change at all. The file size does not change and I do not see any difference in the q file. Is there somewhere else where the actual message is stored that I am missing or is this the main problem with trying to do file replication of MQ? |
Do a display of curdpeth on that queue, if you see that change, then you should be happy ... don't look at the physical file system. _________________ -wayne |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Mon Jan 08, 2007 9:44 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
sroach76 wrote: |
Thanks for the tips. I was finally able to put and get a message on the server. I think it was an issue with the '!' I tried another queue named TEST and everything worked fine ... |
A Q, which contains dots ('.') in its name, is transferred to a file in a directory, which contains an exclamation mark ('!').
sroach76 wrote: |
... I hear what you are saying about file replication probably won't work but I want to test it just so I can be sure. I have tried putting a message in the TEST queue on the primary server and am replication the entire /var/mqm filesystem. But when I add this message manually with the amqsputc command I do not see the /var/mqm/qmgr/NAME/queues/TEST/q file change at all. The file size does not change and I do not see any difference in the q file. Is there somewhere else where the actual message is stored that I am missing or is this the main problem with trying to do file replication of MQ? |
If possible, messages are only stored in the memory and not physically in the Q file. Define the Q TEST with option DEFPSIST(YES), put a message to the queue and stop the queue manager. Now you should find the message in the queue file. _________________ Regards
Hubert |
|
Back to top |
|
 |
sroach76 |
Posted: Mon Jan 08, 2007 12:14 pm Post subject: |
|
|
Novice
Joined: 11 Sep 2006 Posts: 15
|
Thanks for the help. I understand that the amqsputc command might not be putting "persistant" messages into the queue. Persistant messages are written to logs and queue data files so that should let me replication them. But I have confirmed that the queue named "TEST" does have DEFPSIST set to YES:
DISPLAY QUEUE(TEST)
5 : DISPLAY QUEUE(TEST)
AMQ8409: Display Queue details.
DESCR( ) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(TEST)
CRDATE(2003-02-04) CRTIME(10.35.57)
ALTDATE(2003-02-17) ALTTIME(15.00.22)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(YES)
And when I use amqsputc to put a message on the TEST queue and compare the current depth of the primary and secondary servers they are still not in sync. The secondary still shows a depth of 0 vs 1 on the primary. I have also asked our application guys to put a message on the queue in the morning since I know that is persistant but I wanted to test it before if possible. Any final suggestions? |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jan 08, 2007 12:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Stop the secondary queue manager.
Have them stop the primary queue manager after doing the PUT on the primary
Then replicate your file systems.
Then start the secondary and check the queue depth. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
sroach76 |
Posted: Mon Jan 08, 2007 1:29 pm Post subject: |
|
|
Novice
Joined: 11 Sep 2006 Posts: 15
|
Thanks Jeff that seemed to work! I was able to finally see the queue depth increase to 3 on the secondary just like the primary was set to before I stopped it. Thanks! Now was it the secondary being down first and then starting up after the primary went down that caused this to work? Or was it the primary being shutdown before starting up the secondary? I just want to see if in a true disaster situation where the primary never receives and endmqm command and just crashes if the same situation would still work and the message get moved over once I started up the secondary's queue mgrs. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jan 08, 2007 1:32 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It's probably just replicating the file systems after primary is stopped - so that they are in a consistent state.
They should be in a needing-recovery-but-consistent state if the primary queue manager failed.
And you will need to have both the secondary and the primary stopped before you replicate the file systems. As we keep saying - the file systems are not in a consistent state unless the queue manager is down.
You should be using linear logging in this situation, and you should run rcdmqimg as often as you can possibly stand to. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue Jan 09, 2007 1:02 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
sroach76,
you misunderstood! Messages (persistent or not) are generally only hold in the memory. When an application puts a message to a queue whilst another application is reading the queue, message will mostly not put to the queue file. But when you put a persistent message to a queue and then stop the QMgr, you should find the message in the queue file - a non-persistent message would be removed.
You should also see the message in the queue file, when no reading application has opend the queue (I did a short test).
On the other hand, persistent message are always written to the transaction log (the S00....LOG files) - non-persistent messages never (except for NPMCLASS(HIGH) ).
The transaction logs and the Q files may become out of sync, when you copy them during the QMgr is active. Jefflowrey gave you a perfect description, how to replicate a QMgr. _________________ Regards
Hubert |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 09, 2007 2:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Actually, non-persistent messages don't get removed until queue manager startup. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
pathipati |
Posted: Tue Jan 09, 2007 11:51 am Post subject: |
|
|
Master
Joined: 03 Mar 2006 Posts: 296
|
Quote: |
Actually, non-persistent messages don't get removed until queue manager startup. |
Jeff, in this case is there any way to retrieve non persistent messages? |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 09, 2007 12:04 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You can't retrieve them from the q files, that I know of.
You can set the NPMCLASS on the queue to prevent them from getting deleted at startup, though. But you kinda have to do that before you shut the qmgr down... _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
pathipati |
Posted: Tue Jan 09, 2007 12:24 pm Post subject: |
|
|
Master
Joined: 03 Mar 2006 Posts: 296
|
Quote: |
You can set the NPMCLASS on the queue to prevent them from getting deleted at startup, though. But you kinda have to do that before you shut the qmgr down... |
You mean NPMCLASS should be set to HIGH?
If so, if I define queue with NPMCLASS as HIGH then can I prevent loss of non persistent messages?
Correct me if I am wrong..
Thanks |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 09, 2007 12:26 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Well, what does the documentation say on NPMCLASS? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
pathipati |
Posted: Tue Jan 09, 2007 12:49 pm Post subject: |
|
|
Master
Joined: 03 Mar 2006 Posts: 296
|
Jeff thanks for clarification..
Quote: |
Non-persistent messages put to this queue are not discarded in the event of a queue manager restart. Non-persistent messages put to this queue may still be lost in the event of a failure. |
|
|
Back to top |
|
 |
|