| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| AMQ6207 and nonpersistent messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| jdye |
 Posted: Fri Jan 26, 2007 7:03 pm Post subject: AMQ6207 and nonpersistent messages |
 |
|
Apprentice
Joined: 14 Jun 2002
Posts: 31
Location: Kansas City
|
While one of our vendor applications was reading and writing messages, we received error "AMQ6207: Failed to attach shared memory segment as Segment table is Full." After researching this error, I suggested that they need to have their application set the environment variable to EXTSHM=ON per MQ documentation.
The issue is that the users believe that the messages that were being processed during this issue were lost (by MQ of course ). These messages were nonpersistent. Since nonpersistant messages live in memory, and not knowing exactly how AIX manages memory, I figured that it was a possibility. I also figured it was possible that the application read the message destructively, was impacted by the memory issue while attempting to process the message and put the reply message, and didn't rollback the message original message.
I know MQ know claims assured delivery when the message is persistent, and that nonpersistent message will be lost if the queue manager fails or is brought down, and also if you are using 'nonpersistent message speed fast' on a channel and the channel fails, but I wasn't aware of any other situations where a nonpersistent message would be lost.
I hate to see MQ take the blame on a problem if it wasn't at fault, but if that is circomstance that a nonpersistent message could be lost, it would be good to know.
Any ideas? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sat Jan 27, 2007 5:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
First off, if the client really can't stand to lose the message, then it should be persistent. That is, if they've chosen to make their messages non-persistent, they've accepted that they can get lost.
Secondly... eliminate application problems first.  It's entirely possible that the error occuring with shm was causing the vendor application to fail to deal with the messages properly, in some manner or another, and also failing to report on what it was doing properly. You've said this is possible, and it certainly is possible.
Third. With WebSphere MQ Version 6, the setting of the EXTSHM variable has no effect on the shared memory used by WebSphere MQ.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jdye |
| Posted: Mon Jan 29, 2007 9:00 am Post subject: |
|
|
Apprentice
Joined: 14 Jun 2002
Posts: 31
Location: Kansas City
|
Thanks for your reply.
First, the client chose to use nonpersistent messages for performance reasons understanding that under a few uncommon circumstances they could lose messages. They can recover them, it's just a pain for them, and thinking that MQ lost the messages under circumstances that they where not told about (queue manager didn't go down and there was not channel failure), they were concerned.
Secondly, as it turns out, they now finally realize that MQ didn't lose their message, it was their application that failed to process the message once they retrieved it. In this case, it wouldn't have made a difference if the message was persistence or not, the problem was an application issue after the fact.
Thirdly, this is a 5.3 queue manager. From the documentation in the AIX quick beginning manual,
"With WebSphere MQ for AIX, V5.3, queue managers use the AIX extension EXTSHM, which allows more than 10 segments to be attached by a single process. This is enabled by exporting the environment variable EXTSHM=ON in the environment before a process is started (the variable must be in upper case).
To take full advantage of this facility, set the environment variable EXTSHM=ON in the environment of all WebSphere MQ applications before they are started. All WebSphere MQ queue manager processes will set this variable for the lifetime of their process, if it is not already set when the queue manager is started. "
The way I read it is that the variable should be in both the queue manager process and the application, but I have read a post by a user indicating that in their testing, it didn't seem to matter whether or not it was set in the environment for MQ or not, but it had to be set in the environment of the application. Does this sound correct? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 29, 2007 11:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd make sure it was set in both environments - just so I could sleep at night.
You otherwise didn't indicate v5 or v6, so I went with v6.
You should tell your client to start planning their migration to v6. V5.3 goes out of support in the next year or so.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
