We are using the Websphere MQ Adapter version 3.0 in a high volume environment. A “listen” operation is used to detect the arrival of a message in the MQ queue and to invoke an IS message handling service. Because sync point processing is being used, the message remains in the queue until the handling service invokes the MQ adapter “wm.MQSeries.runtime.commit” service.
The MQ Adapter user guide says that connection pooling is not used for Get, Put or Listen operations when sync point processing is being used.
Does this mean that the adapter must reestablish the connection to the MQ Queue Manager each time a message is retrieved or is a permanent connection maintained with the MQ Queue Manager while the “listen” operation is active?
What performance tuning guidelines are there for high-volume MQ environments when sync point processing is employed?
I confirmed today that while the Websphere MQ adapter does not use connection pooling when accessing queues using sync point processing, it does not have to reestablish the connection with each get or put. The connection is maintained until a commit or rollback service is invoked with that connectionID.
BTW, version 6 of the Websphere MQ adapter is planned for early Q1 2004. It will use the 6.0 Adapter Runtime (ART) and will therefore be able to leverage the ART’s connection management and logging features and will allow developers to create adapter services using Developer.
Early indications are that the new adapter is significantly faster (in test environments) than the current 3.0 version.
I’m running IS 6.0.1 SP2 with WebSphere MQ Adapter 3.0 SP3 Fix 6-12 on Solaris 8. I’m pooling my connections with min of 5, max of 20 and Inactive Lifetime of 10 sec. We are noticing that connections are not being torn down on the MQ side once they have been created by my Request/Reply Message handler service. After speaking with our MQ administrator, I learned that MQ server doesn’t tear down a connection unless the client explicitly requests it. This doesn’t seem too odd to me b/c I know the WmDB package behaved similarly WRT connection management. What do you all recommend as a best practice for closing connections that are opened?
The recently released 6.x version of the Websphere MQ Adapter leverages the IS 6.x ART’s connection management capabilities. I would expect that this has resulted in greater stability and improved performance.
Mark - Yes, I’ve installed the new WebSphere MQ Adapter 6.0 on our sandbox and played around with it a bit. It looks very much like the JDBC Adapter 6.x since, as you said, it leverages the ART’s functionality.
Unfortunately, we are currently bound to the the 3.x MQ Adapter. I believe there is a C function called “mqdisc” (i.e., MQ disconnect) and I was hoping the MQSeries provided similar built-in service.
Has anyone found a similar method exposed in MQ’s java API that will let me explicitly close a connection to MQ?
I have tried to find the exact solution to this in the forums but no luck…
I am having a problem in taking the MsgId from a msg on the request queue and mapping this to the CorrelId of the response. Some how the last 3-4 char of the Corrrelation id get changed from the request to response, i was reading thru some pages and there was a mention that this is a known bug. Has anyone in here exp this and found a way to resove this.
I am using IS 4.6, MQ Adapter 3.0. My request and response queues are set up between websphere and IS.