| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| AMQMDNET connection pooling? |
« View previous topic :: View next topic » |
| Author |
Message
|
| wcaneira |
 Posted: Thu May 18, 2017 5:34 am Post subject: AMQMDNET connection pooling? |
 |
|
Newbie
Joined: 07 Apr 2017
Posts: 5
|
A teammate told me that in my AMQMDNET application I need to ensure I pool usage of the MQQueueManager objects.
When I do a simple test w/netstat I notice almost a 1:1 correlation between MQQueueManager objects and TCP connections.
1) Wanted to confirm, given my netstat observation: is the purpose of pooling the connections in this case to share TCP connections to the MQ Server?
2) Is my teammate correct that consuming applications should program support for this, that AMQMDNET expects the client to do it?
In lieu of pooling, would it be inadvisable for web applications to simply create and dispose of MQQueueManagers for each HTTP request? I'm guessing the answer is YES, as HTTP request volume increases the number of TCP connections will grow linearly.
In lieu of pooling, would it be inadvisable for batch-style applications to simply hold a single MQQueueManager instance for their operations and then dispose of it?
3) Am I correct in my observation that MQQueueManager is IDisposable and therefore .Dispose() should be called?
I don't mind trying to implement the object pool myself - there are .NET examples of the pattern available online - I am just trying to understand before I write potentially unnecessary code.
As MQQueueManager is IDisposable, I believe a custom pool would need to monitor with a timer thread for inactive objects and .Dispose() of them properly, since the client cannot. So the custom pool would be a little more sophisticated in that regard. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu May 18, 2017 6:06 am Post subject: Re: AMQMDNET connection pooling? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| wcaneira wrote: |
| 1) Wanted to confirm, given my netstat observation: is the purpose of pooling the connections in this case to share TCP connections to the MQ Server? |
That's generally the purpose of any kiund of connection pooling
| wcaneira wrote: |
| 2) Is my teammate correct that consuming applications should program support for this, that AMQMDNET expects the client to do it? |
The documents on the AMQMDNET interface should explain this.
| wcaneira wrote: |
| In lieu of pooling, would it be inadvisable for web applications to simply create and dispose of MQQueueManagers for each HTTP request? I'm guessing the answer is YES, as HTTP request volume increases the number of TCP connections will grow linearly. |
NO.
MQ does not close connections immediately. If you create and dispose of connections rapidly, you will rapidly fill up available sockets on the queue manager machine. This is BAD.
| wcaneira wrote: |
| In lieu of pooling, would it be inadvisable for batch-style applications to simply hold a single MQQueueManager instance for their operations and then dispose of it? |
No. MQ Applications generally create *one* connection to a queue manager, and send or consume messages over that connection until they're done.
| wcaneira wrote: |
| 3) Am I correct in my observation that MQQueueManager is IDisposable and therefore .Dispose() should be called? |
Again, this will be part of the .NET api documentation.
But you likely need to close the connection before you do anything to delete/dispose/remove the MQQueueManager object,
| wcaneira wrote: |
I don't mind trying to implement the object pool myself - there are .NET examples of the pattern available online - I am just trying to understand before I write potentially unnecessary code.
As MQQueueManager is IDisposable, I believe a custom pool would need to monitor with a timer thread for inactive objects and .Dispose() of them properly, since the client cannot. So the custom pool would be a little more sophisticated in that regard. |
You know that an MQQueueManager object is inactive when you get an error trying to use it. Then you can try to reconnect/recreate it. Any other kind of monitoring may not be as useful as you'd think.
You should also consider how many MQ operations you will be doing at one time, and see if you really need a pool at all. MQQueueManagers are synchronized across threads. So unless you really need to send more than one message *simultaneously*, you may not need more than one connection/MQQueueManager connection.
That assumes you are always talking to the same queue manager. If you are talking to different queue managers, then you would need one (or more) MQQueueManager objects for each queue manager - this might be pooled or stored in a dictionary/hash of some kind.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| wcaneira |
| Posted: Thu May 18, 2017 10:00 am Post subject: |
|
|
Newbie
Joined: 07 Apr 2017
Posts: 5
|
Thank you for your reply.
I could be looking in the wrong places, but I only see a single page or maybe two of AMQMDNET documentation.
Here's one example: https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q123550_.htm
On that page and the other .NET related pages that link off of it, there is some good information, but I don't see anything related to connection pooling recommendations.
I also don't see any explicit examples or comments showing that the MQQueueManager.Dispose() is necessary, but I guess I'm trained to properly Dispose() of IDisposables.
If you had a specific piece of documentation in mind, please let me know. |
|
| 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
|
|
|
|
