| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How does MQSeries Classes for Java handle unclean shutdown? |
« View previous topic :: View next topic » |
| Author |
Message
|
| nohwal |
 Posted: Sun Oct 12, 2003 9:40 pm Post subject: How does MQSeries Classes for Java handle unclean shutdown? |
 |
|
Newbie
Joined: 12 Oct 2003
Posts: 4
Location: New Delhi, India
|
Hi,
I am using MQSeries Classes fro Java 5.2.1 and using them to connect to WebsphereMQ 5.3. I am facing problem when unclean shutdwon of QueueManager is done. Here is what the problem is:
I have an application which waits infinitely on a queue to receive message. Whenever a message arrives in the queue, some pre-defined action is taken on it. Now, the problem is when I kill my application at the time when it is waiting to receive a message. This leaves a "dangling" handle on the queue that I am using. If I go to MQExplorer, right click on the specified queue and see its status then I can see a handle is active on the queue even though my application is dead. This causes a problem as whenever a new message arrives on the queue, this handle picks up the message and vanishes and hence my one message is lost.
To avoid this problem, I used sync-point to receive messages and used sync-point size to be 1. i.e. I explicitely do queueManager.commit() after receiving each message. However, problem occurrs if I commit after receiving more than 1 message. e.g. if I commit after 10 message are received and I kill my application when it has received only 4 messages (and hence queueMgr is not yet committed). I now try to browse the queue, no messages are seen. If a new message is pushed in the queue now then I can see 5 messages in the queue (4 earlier ones and 1 new). This is explainable because the dangling handle dies after receiving any further message and hence all the messages are rolled-back.
Now, can anyone tell me how can I avoid this dangling handle when an unclean shutdwon takes place? FYI, the problem doesn't appear if the queueManager is shutdwon cleanly using queueManager.disconnect() API.
Any help will be very much appreciated. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Mon Oct 13, 2003 9:44 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
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 |
|
|
| nohwal |
| Posted: Mon Oct 13, 2003 7:29 pm Post subject: |
|
|
Newbie
Joined: 12 Oct 2003
Posts: 4
Location: New Delhi, India
|
Thanks for yor response. I appreciate it.
I understand the behaviour in a much better fashion now. However, What if I am planning to sync-up after let's say 10 messages. In that case, say if I kill my application after it has received 8 messages, then if I re-connect a new application, it won't be able to receive those 8 messages until a new message arrives, the agent drops my 9 (8+1 new) messages , and then the new application will be able to receive messages.
Do you have any work-around to solve this problem.
Thanks a lot in anticipation of your response. |
|
| Back to top |
|
|
| ArvindC |
| Posted: Mon Oct 13, 2003 11:57 pm Post subject: |
|
|
Novice
Joined: 25 Dec 2002
Posts: 14
Location: India
|
| Are you doing some kind of testing? If not, in real life you shouldn't use the unlimited wait option, as suggested earlier. An unlimited wait would also not allow your application to shut down gracefully. So the solution is that you can repeatedly do a get, with a wait interval, in a loop. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Oct 14, 2003 5:26 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
From your original post, it doesnt look like you are doing a CLIENT connection. Even though you did not explictly mention so. Because if you did, then you would not have a dangler under normal circumstances as the Svrconn channel that opens the queue goes down immediately.
Only when you connect your java app using the server bindings, your app has an MQ agent which hangs around even after you kill your app.
As for you putting a message to release the agent is concerned, it is just a mere coincidence. An app putting messages has nothing to do with an agent from another app dying.
How to resolve your issue. Hmm...
One of the easiest wasys is to use Fastpath bindings, in which you dont get an MQ Agent and as soon as your app is killed, all handles are released that were attached to the queue. Now, what i do not know is whether Java api has this feature or not. I have not done this myself. But i am pretty sure it ought be there.
If not, then the only other possible solution is to wait for a while before you reconnect to your application after you have killed the 1st one, so as to give some time to release the handles associated. You have to bear in mind that you are going against the standard MQ rules of gracefully stopping the application hence you have to accordingly give some time for MQ to handle this.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Oct 14, 2003 5:42 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I'd like to respectfully disagree with:
| Quote: |
Only when you connect your java app using the server bindings, your app has an MQ agent which hangs around even after you kill your app.
|
All of my comments were directed toward an application that client connects into an agent. The listener program is what starts this agent.
If I understand your problem, you've found a way to work around the lost message by doing syncpoint. Your problem is the fact that the listener doesn't appear to pick up any messages until you put a new message? I've seen things like this before. I believe the biggest part of the problem was related to the fact that you still have a receiver that is waiting to time-out. Until he does, the new messages are effectively locked. I'd suggest that you go with a get with a timeout (never use unlimited) and that you also look into the HBINT parameter of the channel. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Oct 14, 2003 7:05 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Bower, you are right. I was thinking from only one/two platform point of view, but not family wide. There are a few platforms where an Agent is not created unless specifically asked for as the MCA is fastpath.
Cheers
Kumar |
|
| Back to top |
|
|
| nohwal |
| Posted: Tue Oct 14, 2003 7:19 pm Post subject: |
|
|
Newbie
Joined: 12 Oct 2003
Posts: 4
Location: New Delhi, India
|
Hi,
Thank you for taking interest in my problem.
My client application is definitely making a client connection only. Here is the code:
======MAKE CONNECTION ============
MQEnvironment.hostname = localhost;
MQEnvironment.port = 1616;
MQEnvironment.channel = "nohwal";
MQQueueManager mqqueuemanager = new MQQueueManager("nohwal_QM");
MQQueue mqqueue = mqqmanager.accessQueue("nohwal", MQC.MQOO_INPUT_AS_Q_DEF);
========= RECEIVE MESSAGE ==========
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_WAIT | MQC.MQGMO_SYNCPOINT;
gmo.waitInterval = MQC.MQWI_UNLIMITED;
MQMessage mqMessage = new MQMessage();
mqqueue.get(mqMessage, gmo);
==================================
Now, when I receive N such messages, I do:
mqqManager.commit();
==================================
Now, If my application is killed before I could say commit but after I have received M (M<N) messages, then the dangler remains on the queue. I must push a new message into the queue which will will be received by dangler and then the queue will again show M+1 messages.
I hope the application scenario is clear now. FYI, the channel is of type "Server Connection Channel" and the queue is "Local Queue" type.
Do you have a solution in mind now, or it's something that no-one can do anything about it? I mean doesn't MQSeries queue/channel have some flag which can be set which will detect the dead connection immediately and hence won't leave a dangler?
FYI, this application of mine is not just a testing phase. I have to pick messages from MQSeries queues and have to process them so that they can be used in my internal proceses.
Any help wud be greatly appreciated.
Thanks a million.
+Deepak. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Oct 15, 2003 4:51 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
As i mentioned in my earlier update, it is just a mere coincidence that your dangling agent dies when you put a message onto the same queue.
Also as i mentioned earlier, since this situation was caused by an application termination, it is the responsibility of the application to handle such a situation. You have to wait until the opener has gone away. Need to allow some time for that.
It is like handling a 2033 error when no message is available on queue. Its the applications responsibility since you being a designer of the app need to take into consideration these errors.
As far as i am aware, and i believe i am right, there is no real way out of this. You have to allow enough time for the qmgr to clear off the danglers.
Cheers
Kumar |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Oct 15, 2003 5:39 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
Sorry, but I'm going to have to disagree again:
| Quote: |
As i mentioned in my earlier update, it is just a mere coincidence that your dangling agent dies when you put a message onto the same queue.
|
It actually isn't a coincidence that the agent dies with the new message. The agent dies when it gets a message and attempts to deliver it to your program. Your program has gone away. The agent realizes this, rollsback all of its messages, and then goes away.
mqonnet is right in that there is no real way out of this. The dangler won't go away until something happens that lets him know he needs to go away. This can be accomplished in one of two ways. You can (and should) change your wait from unlimited to something smaller (1 minute?). This will cause the get to timeout and let the agent know you've gone away. The other alternative is to look into the heartbeat parameter to see if you can get something with it to inform the dangler sooner that you've gone away. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Oct 15, 2003 5:54 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Bower, i think what nohwal said was this.
"
Now, If my application is killed before I could say commit but after I have received M (M<N) messages, then the dangler remains on the queue. I must push a new message into the queue which will will be received by dangler and then the queue will again show M+1 messages.
"
Now this would mean that he tried to put a message after he killed his app even though the agent for the earlier app was still hanging around. And in that case, it is just a coincidence that the agent goes away.
From what you said..
"It actually isn't a coincidence that the agent dies with the new message. The agent dies when it gets a message and attempts to deliver it to your program. Your program has gone away. The agent realizes this, rollsback all of its messages, and then goes away.
"
Nohwal is trying to do a put and not a get which would lead the agent to try and deliver it to your app.
An agent is associated with a particular application. Once the app is killed or stopped, the agent cleans itself up. It CANNOT receive any more inputs such as messages.
Cheers
Kumar |
|
| Back to top |
|
|
| eddie |
| Posted: Fri Oct 17, 2003 1:23 pm Post subject: |
|
|
Novice
Joined: 03 Jun 2002
Posts: 13
Location: Philadelphia
|
nohwal,
I've experienced a similar problem of loosing messages due to a program restart.
I did use the 'get under syncpoint' as a work around for this... does your program need to receive more than one message before commiting??? otherwise I would commit after receiving each message. Then you shouldn't find M messages all getting returned to the queue... it should be just the last one.
eddie |
|
| 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
|
|
|
|
