| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Broken connection between Client & Server MQSeries ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| KAKEZ |
 Posted: Mon Jul 21, 2003 1:38 am Post subject: Broken connection between Client & Server MQSeries ? |
 |
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi,
I wonder about the following situation wich is not clear in my mind.
A client application call MQGET with WAIT unlimited option.
1) if the server machine crashes (and obviously the Qmgr also):
- does the client appli receive some information about the situation?
- how is it aware than the MQI channel is broken?
1) if the client appli crashed when the server is ready to answer to the appli after the MQGET
- what does the Qmgr do with the MQGET call?
- does the Qmgr maintain the old MQI channel instance?
- what happens exactly when the client appli connects to the Qmgr again?
thanks a lot to help me understanding this particular point about the MQI channel.
Jack |
|
| Back to top |
|
 |
| clindsey |
| Posted: Mon Jul 21, 2003 6:27 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
Jack,
When the client loses communication with the queue manager, it becomes aware of the problem on the next heart beat interval. By default this value (hbint) on the channel definition is 5 minutes. You will probably want to bring this way down, to say 5 seconds. If you have a clntconn channel def as opposed to just setting MQSERVER, you need to match the hbint value. The actual value is negotiated to the higher of the 2 if they do not match.
When the client goes away, there are no errors that will be encountered on the queue manager side but the queue manager needs to cleans up resources when it finds out the partner socket has closed. This is at the ip stack level and varies by o/s and ip stack. It is a good idea to set keepalive=yes in the qm.ini (or through MQ Services on Windows) so MQ will take advantage of tcp keepalive to know when a client has gone away.
Charlie
Last edited by clindsey on Mon Jul 21, 2003 6:55 am; edited 1 time in total |
|
| Back to top |
|
|
| mqonnet |
| Posted: Mon Jul 21, 2003 6:28 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Shall try and answers your questions....
1) On some platforms you do get the notice back, saying that the Server or MQ itself died. But on most others, i dont think you do. And i doubt there is any way out of this. You have something called MQGMO_FAIL_IF_QUIESCING that you could use, but again this helps only when the qmgr is coming down or is brought down. Dont think it is applicable in "pull the plug" scenarios. Also in the otherwise situations this is what i got from the manuals..
"If MQGMO_FAIL_IF_QUIESCING is not specified and the queue manager or connection enters the quiescing state, the wait or signal is not canceled. "
2) (think you meant 2, instead of 1 :)...)
---It is cancelled.
---No.
---It connects as if it is a totally new application, neither the app nor the qm has any knowledge of the previous error state of the application.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Mon Jul 21, 2003 10:33 pm Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi Charlie,
thanks for replying;
you say:
> "When the client loses communication with the queue manager, it becomes aware of the problem on the next heart beat interval"
is that to say that the MQI stub at the client machine is able to send a heartbeat flow?
I thought that heartbeat flows were sent only by the SVRCONN MCA and only in the case of an MQGET WAIT issued by the client appli - as explained in the DEFINE CHANNEL command for a CLNTCONN channel!
> Also you say that Keepalive function may run between CLNTCONN and SVRCONN sides - what side is able to send the TCP packet to which other side? - Not very clear for me.
In that case, after having discovered that a client connection has disappeared is the Qmgr able to clean up the resources allocated for the old client-server connection?
If nothing is done, during the new next MQCONN connection from the client is the parameter AdoptNewMCA (if coded within qm.ini) used to overwrite the old SVRCONN always running?
(by the way the only value possible to let AdoptNewMCA available for a CLNTCONN channel is "All" because nothing defined for that type of channel).
+++
Hi Kumar,
thanks for replying,
but questions more:
> you say that when the client appli crashed the MQGET call is cancelled by the qmgr - but does it do a backout for the message read by the Get call? - assuring that this mess is not lost?
> and the qmgr also delete the SVRCONN process wich is associated with the CLNTCONN broken? - or we have to clean up the SVRCONN process?
Jack |
|
| Back to top |
|
|
| clindsey |
| Posted: Tue Jul 22, 2003 6:13 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
I believe having an outstanding MQGET with wait would be the only case where an hbint would be needed. For any other cases, the client would find that the connection is broken when it issues the next mqi call, in which case I believe you will get a 2009, connection broken return code.
I believe also that the keepalive ping is only sent from the server side to see if the socket connection is still valid at the client side. The default for AdoptNewMCA is NO so the default behavior is to spawn a new amqcrsta process on the next connection. If you have a problem with many amqcrsta processes building up, then it would sure help to set this to ALL.
Charlie |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 22, 2003 7:00 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
If the message has been delivered from MQ's point of view, then it cannot recover in the event of a "pull the plug scenario". But if the message is in flight, and you are using either Persistent messages or Syncpoint, the message would be backed out.
If your server crashed, then obviously the svrconn channel would also die. When your client application dies, the svrconn channel may show as running for a little while as it needs to clean up and eventually it dies too. So, in both cases MQ cleans it up.
Cheers
Kumar |
|
| 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
|
|
|
|
