|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQOpen GET and PUT contention |
« View previous topic :: View next topic » |
Author |
Message
|
daveeason |
Posted: Mon Apr 10, 2006 6:32 pm Post subject: MQOpen GET and PUT contention |
|
|
Novice
Joined: 14 Jul 2005 Posts: 18 Location: Canberra, Australia
|
Hey,
Solaris platform, MQ 5.3 CSD 11, Forte C++ application.
Application design question, We have an application that is retrieving messages from a queue in a polling manner by specifying the GMO_Wait interval and re-issuing a GET if the wait interval expires which seems appropriate given the frequency with which messages are arriving on the input request queue (10+ per second).
Once a message is retrieved the application starts a new thread and attempts to PUT a response to the reply2Q and reply2QMgr specified in the request msg by calling MQOpen. The issue we are seeing is that the MQOpen does not complete succesfully until the GMO_Wait interval expires.
Is is possible to configure this GET & PUT to avoid this contention so that the MQOpen for output can be processed immediately without delaying?
Regards, thanks in advance for assistance. _________________ Dave Eason
Addis |
|
Back to top |
|
 |
daveeason |
Posted: Mon Apr 10, 2006 7:51 pm Post subject: |
|
|
Novice
Joined: 14 Jul 2005 Posts: 18 Location: Canberra, Australia
|
Ok so I have subsequently discovered that the contention that I was referring to is actually the documented behaviour for the MQCONN Hconn object within the scope of a thread.
***
From the MQ infocenter doco
"...the scope of an MQCONN or MQCONNX call is usually the thread that issued it. That is, the connection handle returned from the call is valid only within the thread that issued the call. Only one call may be made at any one time using the handle. If it is used from a different thread, it will be rejected as invalid. If you have multiple threads in your application and each wishes to use WebSphere MQ calls, each one must individually issue MQCONN or MQCONNX. Alternatively, consider Shared (thread independent) connections with MQCONNX..."
***
I will look into the alternatives that this suggests, thanks anyway (and thanks Paul for the tip
Dave _________________ Dave Eason
Addis |
|
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
|
|
|
|