| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Losing message on Websphere App Server Shutdown |
« View previous topic :: View next topic » |
| Author |
Message
|
| asavidge |
 Posted: Tue Sep 02, 2003 11:40 am Post subject: Losing message on Websphere App Server Shutdown |
 |
|
Newbie
Joined: 02 Sep 2003
Posts: 2
|
Hi
I have a strange problem using MQ and a Java Listener. I am testing a catastrophic failure of the Application Server while processing messages. If I am waiting for a message in the queue the same time the WebSphere App Server shuts down and a message arrives in the queue after the App Server shuts down, the message will be retrieved off the queue but of course the Java process isn't running any more and nothing happens. What concerns me is the message is retrieved off the queue at all, it's almost as though there is a handle or thread running outside of my code.
Any ideas would be greatly appreciated.
Code snippet below:
// Create a connection to the queue manager
qMgr = new MQQueueManager(llbMQInfo.getQManager());
// Set up the options on the queue to open...
int getOpenOptions = MQC.MQOO_INPUT_AS_Q_DEF |MQC.MQOO_INQUIRE;
// Now specify the queue that we wish to open and the open options...
masterQueue =qMgr.accessQueue(llbMQInfo.getRequestQueue(), getOpenOptions, null, // default q manager
null, // no dynamic q name
null); // no alternate user id
// Define a MQSeries message buffer to receive the message into...
MQMessage theMessage = new MQMessage();
// Set the get message options...
MQGetMessageOptions gmo = new MQGetMessageOptions(); // accept the defaults
// Make sure the get waits for the message to arrive in the queue...
int getOptions = MQC.MQGMO_WAIT;
gmo.options = getOptions;
gmo.waitInterval = 3000; // wait 3 seconds and loop again...
gmo.matchOptions = MQC.MQMO_NONE;
while (listen) {
try {
processMessages(masterQueue, gmo, theMessage);
} catch (MQException mqex) {
// squash the 2033 - wait for another message
if (mqex.reasonCode == 2033) { }
}
} |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Sep 02, 2003 8:35 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Your code snippets only connects and then opens the queue. It does not have the get method.
In case you don't know, the get method will only take a few milli-seconds (can't remember the exact number) to retrieve a message. But WAS will take much longer than that to shutdown. So, this will be a tough scenario to exactly time. Plus you are missing GMO options for message integrity.
If you want to make sure that your application fully processes a message then you need to use Local UOW (Unit of Work). Add the MQC.MQGMO_SYNCPOINT to your GMO options. Then after you process each message, issue a commit.
If your appliaction crashes or something in-between crashes, then the queue manager will do a Backout of your message (it will put it back on the queue).
later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| asavidge |
| Posted: Wed Sep 03, 2003 4:23 am Post subject: |
|
|
Newbie
Joined: 02 Sep 2003
Posts: 2
|
Hi Roger
Thanks for the information, I neglected to put the code in for the getMessage - it was in the processMessage method. Code snippet below. I will make the changes you suggested with the syncpoint and message integrity message options. If you see something else - let me know. Really appreciate your help!
// The following is sample code to show how to process
// message retreived off the queue.
// Set parameters so that messages to be retrieved will not try
// and match previous messages
aEventMessage.messageId = MQC.MQMI_NONE;
aEventMessage.correlationId = MQC.MQMI_NONE;
// get the message off the queue...
aMasterHandlerQueue.get(aEventMessage, aGMO);
// And prove we have the message by displaying the message text
(aEventMessage.getMessageLength());
System.out.println("Msg " + msg);
aEventMessage.clearMessage();
processEvent(msg); |
|
| Back to top |
|
|
| nohwal |
| Posted: Sun Oct 12, 2003 9:03 pm Post subject: similar problem. |
|
|
Newbie
Joined: 12 Oct 2003
Posts: 4
Location: New Delhi, India
|
Hi, I have a code similar to yours with the only difference being that the wait is infinite. In this case, if I have an infinite wait in my code and I exit the application WITHOUT calling queueManager.disconnect() then this strange problem occurrs. A dangling handle remains on the queue that I was using. If you use MQExplorer and right click on queue and check its status, it shos one handle alive even though my application is dead. This is the handle that causes the problem. If I now push a message on this queue, this dangling handle picks up the message and vanishes.
To avoid this problem I used the Syncpoint behaviour but this also has the problem.If I specify the size of the syncpoint to be greater than 1 then also the problem will be present.
Acdcording to my analysis, MQSeries(WebsphereMQ) is unable to detect the "non-clean" shutdown of QueueManager and maintains a dangling handle to the queue which is deleted once a fresh message is made available to this handle.
Does anyone know how to fix it? |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Oct 13, 2003 9:46 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
Here is my reply to a similar thread:
It sounds like things are working the way that they are supposed to if you are running with a client connection. You make a client connection to an agent on the qmgr that processes all of your requests.
In the non-syncpoint situation, the agent receives the message, attempts to send it to your program, realizes you're gone, and throws it away.
In the syncpoint situation, the agent receives the message, attempts to send it to your program, realizes you're gone, and puts it back on the queue.
I've always been told that the way to get around the lost messages is to use syncpoint. I've also been told not to use unlimited waits. With a time-out, the agent can check on the receiver periodically. You can also use the heartbeat to have the agent check on the client program. |
|
| 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
|
|
|
|
