| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Keeping Queues open for reuse? |
« View previous topic :: View next topic » |
| Author |
Message
|
| bdoll |
 Posted: Fri Feb 10, 2006 4:25 pm Post subject: Keeping Queues open for reuse? |
 |
|
Newbie
Joined: 10 Jan 2006
Posts: 5
|
I'm writing a Java application that will be using the MQ Standard Java API to integrate with a locally running MQ Queue Manager (6.0). The application will use a globaly scoped Manager component to centralize the access to MQ.
One obvious bonus to centralizing the MQ access in this global component is the reuse of the MQQueueManager. Within this management component, there will be one MQQueueManager instance, which is used for all transactions. This allows us not to waste time creating and destroying a new MQQM instance for each transaction.
Now that I'm looking over the various queues that this application will be interacting with, I'm wondering if the same reuse could apply to the MQQueue instances.
If all the queues are designated as either inbound or outbound queues, than the queue open options would be the same for a specific queue, each time it was opened. If that is the case, it seems that opening up all of the queues once and keeping references to all of them, would allow for even more efficiency.
If a MQQueue object is opened for each of these queues in the beginning, are there any forseeable issues with keeping those objects around to continually use them for all future transactions?
Essentially, the code for any of the transactions (for puts and gets) would then only involve finding the right queue for the message, and sending or getting it from that queue. No need to create the connection manager (as discussed earlier), nor the queue object that it is communicating with.
Would anyone like to speak of their experiences in the best approach for this type of solution? Centralizing access to the MQ API through a global component that hopes to configure and initiate all the necessary objects in a reusable fashion?
Any insight on the ability to keep queue objects open would be greatly apprecaited! This board has been a great help already in just reading other posts.
Thanks!
b |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri Feb 10, 2006 4:49 pm Post subject: Re: Keeping Queues open for reuse? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bdoll wrote: |
One obvious bonus to centralizing the MQ access in this global component is the reuse of the MQQueueManager. Within this management component, there will be one MQQueueManager instance, which is used for all transactions. This allows us not to waste time creating and destroying a new MQQM instance for each transaction.
Now that I'm looking over the various queues that this application will be interacting with, I'm wondering if the same reuse could apply to the MQQueue instances. |
Think through the implications for security - if indeed there are any in the application as a whole. When an app connects, it has to have the correct authorizations. Likewise when it opens a queue. If you have a range of users in your system, then allowing them to use cached handles might not be the right thing to do, as this might bypass security mechanisms you would want not to bypass.
Other than this, I don't see an obvious architectural problem with what you're thinking here. However, I'd make the point that managing shared state in a reliable and scalable way is no small job, and MQ has already done a good job of this so you don't have to.
Also, regarding the reason for considering this in the first place: think (and analyse) carefully what performance gains you really stand to make. Connections to the queue manager, and opening queues, is not very expensive these days (it is much better than it used to be a few releases ago, at least). I would suggest initial doubt about whether the time cost of a connect and open are going to be noticeable compared to the other time being spent in the system.
Hope this helps.  |
|
| Back to top |
|
|
| bdoll |
| Posted: Fri Feb 10, 2006 5:05 pm Post subject: |
|
|
Newbie
Joined: 10 Jan 2006
Posts: 5
|
You bring up some great points.
As for security, the application itself is the "user" in this case, and all queues have the same access privs, so with that, the security would remain the same in either case. (if i open the queuemanager each time, i'll be using the same user/pass info anyway)
As for the performance gains, this is another good point. I was speaking with an engineer from IBM (during some early architectural discussions of this project) and he was the one who mentioned that we should centralize the access of the Queue Manager due to the performance gains of not opening and closing it every time.
I haven't done any research to substantiate this however, so you may very well be right that in the most recent version this is somewhat moot.
I may however, go both routes and do some performance testing. This way I can know for sure what benefits there may be. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 10, 2006 5:38 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
A wise approach.
It's up to you of course, but here is my $0.02. Basically, I would begin by assuming the best of MQ's connection and open performance. This enables more attention to be focussed on the business logic early in development. I'd keep the architecture general of course - eg. using a ConnectionAndQueueManager class that is a simple pass-through to the plain connect/open mechanisms, but can be a drop-in replacement with a caching implementation later if desired. If initial performance profiling reveals that (a) the program is spending significant time in MQ connect and open calls compared to the rest of the work being done, and (b) this is hurting performance to such a degree that the Requirements are in danger of being broken, then there is justification for looking into caching.
Just my $0.02 of course. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 10, 2006 9:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And as a byplay to this discussion have you looked into the JMS implementation with the automatic caching mechanism from the APP Server?
Have a special class that holds the QCF and the Connection (time consuming)
Have each thread create its own session(requires nearly no time at all) and your transactionality should be safe.
[edit] But remember as well that connection.start() and connection.stop() may be used to control some behaviors and will affect all open sessions created from said connection. There may be your reason for a specific connection for each type of usage. This is the main reason why the app server caches the connections.[/edit]
Enjoy 
_________________
MQ & Broker admin
Last edited by fjb_saper on Sat Feb 11, 2006 6:05 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Feb 11, 2006 4:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess I'm not clear if by "global component", you mean that some piece of long-running code that is accessed by every user from every machine, or if you mean some piece of shared code that is included in every instance of the application?
Also, it's not clear if you're using an application server or if each instance of the application is running in a standalone mode on each user's machine.
If you are using an App Server, then I will agree with fjb_saper. Use JMS, and don't worry about most of this stuff. The AppServer will handle connection caching for you, and it can handle caching queue destinations as well (although most people don't bother, as they open the destination early and close it last, and do lots of work in between).
If you're using standalone applications, then in order to have a piece of long-running code that is accessed by every user - then you have to make calls across the network to access MQ which will then... make calls across the network. As has been said, it's a lot better to just use MQ in the first place.
Yes, in an application, it is best practices to open a qmgr connection once rather than many times. But it's not really best practices to share that one connection across the entire enterprise. One per application is the standard, and MQ is built to work that way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bdoll |
| Posted: Sat Feb 11, 2006 9:21 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2006
Posts: 5
|
I didn't mention many application details earlier mostly because I thought it would just complicate the discussion, but in my scenario:
- the app is a web-based application, running inside an application server (not ws)
- "global component" in this case means a globally scoped configured class in which one single instance is created and available to the running application.
- there are more than one web application instance running per machine, so there will be more than one of these global components per physical server, upon which one mq server instance is running
- we're using the base Java API, mostly because we've evaluated both and found the JMS API to be possibly more of a headache than necessary. our requirements are simple, and we like the more granular control available in the standard java api.
from what i'm hearing, there does not seem to be much expense in opening a particular queue for sending or receiving information. mostly because i've already written the code i desribed in the original post (but have not tested), i'm hoping to perform some performance metrics on both options that i'll post here later.
what i was hoping to find out, was if there are known bad things that can happen if you do cache the open queues. it sounds like because possibly the performance is neglegable, it's not a popular approach, and maybe we're not sure what the issues may be.
if the performane comparison is indeed neglegable, than i will open a connection each time, rather than caching them, just to not have to wonder if i'll have issues down the line. however, if performance is greatly improved, i may need to explore this in more detail.
since this is a web-based application for customer use, any help reducing latency caused by my waiting for response messages from the queues can have a big positive effect. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 11, 2006 6:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Look at the base java API there is something to be used for Pooling.
You say you are using a webserver. If it is J2EE I would strongly suggest that you move to JMS and take advantage of the pooling, caching, JAAS authentication, MDBs etc...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Feb 13, 2006 2:06 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| 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
|
|
|
|
