| Author |
Message
|
| jefflowrey |
 Posted: Mon Feb 04, 2008 9:59 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ shouldn't take 6 minutes to close a connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| guccica |
| Posted: Mon Feb 04, 2008 10:20 am Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
| jefflowrey wrote: |
| MQ shouldn't take 6 minutes to close a connection. |
hi, just double confirm with the issue.
Only the connection which act to get the message only facing this issue.
For the connection which act to put message, dont have the particular issue.
Just wondering is it because the get message option i use?
//Set Get Message Option
gmo.setOptions( MQGMO_WAIT | /* wait for new messages */
MQGMO_FAIL_IF_QUIESCING ); /* but not is mqm stoppping */
/* time to wait to get MQ message */
gmo.setWaitInterval(500);
Please advice...
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 04, 2008 10:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Where is the code that closes the connection?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 04, 2008 10:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| guccica |
| Posted: Mon Feb 04, 2008 10:49 am Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
| jefflowrey wrote: |
| Where is the code that closes the connection? |
Thanks for reply.
Here is the code that close the conneciton
for(int i=0; i<100; i++)
{
pgMQObj[i].mpOutputQueue.setCloseOptions(MQCO_DELETE); //close option
pgMQObj[i].mpOutputQueue.close(); //close output queue
pgMQObj[i].mpInputQueue.setCloseOptions(MQCO_DELETE); //set close option
pgMQObj[i].mpInputQueue.close(); //close input queue
pgMQObj[i].mpOutputManager.disconnect();
pgMQObj[i].mpInputManager.disconnect();
}
It is called when program quiting. |
|
| Back to top |
|
|
| guccica |
| Posted: Mon Feb 04, 2008 10:50 am Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
| PeterPotkay wrote: |
http://www.mqseries.net/phpBB2/viewtopic.php?t=11375&highlight=heartbeat+timeout
Explains MQ API calls for an MQClient taking a long time. So, what's your Hearbeat set to on the SVRCONN channel? |
Hi thanks for the link..will read trough it.
btw, my heartbeat value was 1.
pgMQObj[i].mpOutputChannel.setHeartBeatInterval(1); |
|
| Back to top |
|
|
| guccica |
| Posted: Tue Feb 05, 2008 7:54 am Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
Hi PeterPotkay,
After read from the link provided, will the setting of heartbeat interval to bigger value will helping on this issue?
As we know the timeout for tcp/ip was 60 second. So we would set the value to some value bigger than 60 seconds. So do it matter the problem?
I found that my MQ client still will facing the GET connection closing slow issue. However this problem doesnt shown on PUT connection.
please advice. thanks. |
|
| Back to top |
|
|
| guccica |
| Posted: Tue Feb 05, 2008 9:02 am Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
Hi all
i just found this issue on IBM website.
By any chances does anyone know is my issue cause by this?
IY67232
Click here to see this information via the internet
Abstract SLOW MQ CHANNEL STARTUP/SHUTDOWN DUE TO STATUS TABLE LOCKING
Users Affected Customers using Requester (RQSTR) / Sender (SDR) channel pairs, with AdoptNewMCA parameters specified in the Channels stanza of their queue manager configuration.
Platforms affected:
All Distributed
Error Description Under certain unusual conditions one MQ channel which is starting up can lock the internal channel status table for a relatively long period of time. While this lock is held other channels which are starting or stopping will have to wait before updating their status. One effect is that many channel related commands in runmqsc may take seconds or minutes to complete.
Problem Summary This issue was caused by the MCA adoption logic in the specific circumstances where the SDR side of a RQSTR/SDR pair was initiated while the channel was in REQUESTING status. After the REQUESTING status was resolved, the adoption logic incorrectly assumed that a new SDR instance of the channel would start, after choosing not to adopt the MCA (due to the AdoptNewMCACheck=ADDRESS parameter). This caused attempts to open the XMITQ of the channel while holding the status table lock (for up to 60 seconds).
Problem Conclusion The MCA adoption logic was corrected, and the possibility of the status table being locked was removed. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 05, 2008 9:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Apply the maintenance.
If the problem goes away, that was the cause.....
If not, at least you're on the latest version. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 05, 2008 11:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
that issue is probably not related to yours. you should upgrade anyway.
What is the HB Interval of the SVRCONN definition? Not what you set in your code (1 is a bad value to set by the way) but what is the value on the Queue Manager side?
The larger of the 2 values of both sides of a channel will be used. I'm guessing the MQ Admin did not set the channel's HB to 1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| guccica |
| Posted: Tue Feb 05, 2008 10:48 pm Post subject: |
|
|
Novice
Joined: 18 Dec 2007
Posts: 17
|
| PeterPotkay wrote: |
that issue is probably not related to yours. you should upgrade anyway.
What is the HB Interval of the SVRCONN definition? Not what you set in your code (1 is a bad value to set by the way) but what is the value on the Queue Manager side?
The larger of the 2 values of both sides of a channel will be used. I'm guessing the MQ Admin did not set the channel's HB to 1. |
hI PeterPotkay thanks for the advice.
By any chances may i know what value should i set the heartbit value?
Is it should bigger than the value on MQ Manager? Or it should be same?
Whats the value u will suggest? As what i know the TCP/IP timeout would be 60 seconds. So it should be larger than this value?
Thanks and hope will get response soon. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 06, 2008 10:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| guccica wrote: |
By any chances may i know what value should i set the heartbit value?
Is it should bigger than the value on MQ Manager? Or it should be same?
|
It should be the same as the QM side. The hopefully smart MQ admin choose that value for a reason.
| guccica wrote: |
| Whats the value u will suggest? As what i know the TCP/IP timeout would be 60 seconds. So it should be larger than this value? |
I set mine to 30. That may or may not be good for you. For client channels the HB value doesn't really depend on anything else. Well, if the MQ Admin set the Client Idle Parm (I don't like that) then the client channels HB should be smaller than the Client Idle time.
For QM to QM channels the HB value should be less than the Disconnect Interval value. For QM to QM channels the HB should be less than the TCP Keep Alive time.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
