| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| New features with MQ V7.0 JMS |
« View previous topic :: View next topic » |
| Author |
Message
|
| kevinQ |
 Posted: Mon Dec 15, 2008 7:45 pm Post subject: New features with MQ V7.0 JMS |
 |
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
Hello, MQ gurus,
We are facing a chanllenge from the JMS adapter of a client application opening thousands of client connections to MQ. One of the recommendation is to upgrade to MQ V7. The JMS enhancement of V7 supposedly has the ability to share client connections as long as the sessions are opened using the same connection.
I have a couple of questions, would appreciate if anybody provide any insight or experience with the new feature.
1) To take advantage of this, do we have to install the new MQ V70 JMS classes, and hence the new MQ V70 client on the client application side.
2) Do we have to upgrade the MQ server side to MQ V70 too, or will this new client side JMS feature also apply to older versions (V6) of server side.
Here is some more details, from chapter 7 of the red book, "MQ V7.0 new features":
In previous versions of WebSphere MQ, each instance of the JMS session created by the same parent JMS connection would use a different socket connection to connect to a queue manager. No two JMS sessions shared a socket connection. JMS applications using multiple threads tend to create several JMS session objects from a single connection object for parallel processing of messages. This resulted in a new TCP/IP socket connection being established for every JMS session and more I/O resource utilization on both the application machine and the queue manager machine. This is depicted in Figure 7-5.
With the introduction of conversation sharing in WebSphere MQ V7.0, multiple JMS sessions created from the same connection can be multiplexed across a single TCP/IP socket, as depicted in Figure 7-6. This means that a JMS application creating multiple JMS sessions from a single connection object may now use a single TCP/IP socket. A consequence is that both ends of the socket now have threads which are always receiving data on the socket. This allows heartbeats to travel down the socket from both the ends. In the event of an I/O failure, the WebSphere MQ JMS classes can immediately identify the connection breaking. The JMS application can be more responsive in identifying the failure at all times and not just when an MQGET is outstanding. Conversation sharing thereby reduces the dependency of KEEPALIVE on TCP/IP to detect failures |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Dec 15, 2008 7:51 pm Post subject: Re: New features with MQ V7.0 JMS |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kevinQ wrote: |
Hello, MQ gurus,
We are facing a chanllenge from the JMS adapter of a client application opening thousands of client connections to MQ. One of the recommendation is to upgrade to MQ V7. The JMS enhancement of V7 supposedly has the ability to share client connections as long as the sessions are opened using the same connection.
|
It is commendable that you look at alternate solutions.
However first I would like you to specify what your topology is, and what causes you to have thousands of client connections.
Are you sure that your application is well behaved and closes the connections as soon as they are no longer needed in order to release the resource?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kevinQ |
| Posted: Mon Dec 15, 2008 8:03 pm Post subject: Re: New features with MQ V7.0 JMS |
|
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
| fjb_saper wrote: |
It is commendable that you look at alternate solutions.
However first I would like you to specify what your topology is, and what causes you to have thousands of client connections.
Are you sure that your application is well behaved and closes the connections as soon as they are no longer needed in order to release the resource?
Have fun |
Very good point ... we did have to set the "KeepAlive" paramter to close the unused channels, so the remaining thousands (currently only hundreds, and as the project gets rolled out, it will become thousands) connections are active connections that need to stay. |
|
| Back to top |
|
|
| manicminer |
| Posted: Tue Dec 16, 2008 1:03 am Post subject: Re: New features with MQ V7.0 JMS |
|
|
Disciple
Joined: 11 Jul 2007
Posts: 177
|
| kevinQ wrote: |
I have a couple of questions, would appreciate if anybody provide any insight or experience with the new feature.
1) To take advantage of this, do we have to install the new MQ V70 JMS classes, and hence the new MQ V70 client on the client application side.
2) Do we have to upgrade the MQ server side to MQ V70 too, or will this new client side JMS feature also apply to older versions (V6) of server side.
|
To answer your specific questions, you have to upgrade to both a V7 server and a V7 client to take advantage of these features because they are a re-worked way of connecting to the server which will require both client and server side support. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 16, 2008 3:00 am Post subject: Re: New features with MQ V7.0 JMS |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kevinQ wrote: |
| we did have to set the "KeepAlive" parameter to close the unused channels, so the remaining thousands (currently only hundreds, and as the project gets rolled out, it will become thousands) connections are active connections that need to stay. |
My point is that you should not have to set "KeepAlive" to close unused channels. This should be the responsibility of the application. It doesn't hurt to set Keep Alive on top of it but this should definitely not be your default way of disconnecting. What about uncommitted transactions where the connection gets disconnected?
Have your developers go back to the drawing board until they have satisfied the rule: When no longer needed the MQ resource needs to be released (closed). You cannot leave the close of the resource to the garbage collector. This is just asking for trouble.
You should then see the true usage of the resource and be able to anticipate what the number of needed connections are in prod. You will probably need to bump up MAXChannels for that.
And don't forget, each application needs its own channel if using client connections, so that you as admin can shut them down separately.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kevinQ |
| Posted: Tue Dec 16, 2008 8:43 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
Thanks for the feedback, manicminer. To upgrade MQ on server side, we need to first upgrade the OS, oh well ...
fjb_saper, I agree 100% with you, this application is not behaving well, and the developers need to take care of their business. Unfortunately, this app is from this company called SAP (I see that as part of your name  ), and it takes them long time to deliver a fix like this, but we need to deliver the project at the same time ... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 16, 2008 10:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kevinQ wrote: |
Thanks for the feedback, manicminer. To upgrade MQ on server side, we need to first upgrade the OS, oh well ...
fjb_saper, I agree 100% with you, this application is not behaving well, and the developers need to take care of their business. Unfortunately, this app is from this company called SAP (I see that as part of your name ), and it takes them long time to deliver a fix like this, but we need to deliver the project at the same time ... |
You mean SAP XI?
Remember that SAP does thing a little bit differently and is optimized for the use of SAP JMS. You could always write a SAP/MQ bridge...
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
