| Author |
Message
|
| yalmasri |
 Posted: Mon Apr 05, 2010 1:16 am Post subject: Design Question |
 |
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
I have installed an application that uses JMS to listen to a clustered queue on 3 machines. I also have installed OpenDS on one of those machines and replicated it on another.
Within a cluster of 20 machines (which application machines are part of), I need to send messages to the application after looking up the proper connection factory and destination. For this I have two options:1. Define 3 connection factories, one for each machine, with "client" connection mode.
2. Define 20 connection factories for all cluster machines with "bindings" connection mode.
In first option, I have to specify the remote machine IP, port, and channel, connect directly to it, and manually load-balance between the machines. While in the second, I'll lookup a connection factory that's referring to the local queue manager, and that in turn will send to the remote queue by examining the proper queue manager under which this queue exits.
First option:
Pros:1. Only 3 connection factories are to be defined and nothing need to be added when a new machine is added to the cluster
2. The connection factory name is fixed as far as clients of that application are concerned Cons:1. We have to manually load-balance the requests
Second option
Pros:1. The connection is in bindings mode which is faster than client
2. Getting automatic load-balancing Cons:1. We have to know the name of the connection factory that corresponds to the queue manager where the invocation is coming from
Can anyone advice me concerning those two options? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Apr 05, 2010 12:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Quite confusing and unclear.
- where is the request coming from
- who is processing the request
- what does your MQ network look like
Finally if you just want client load balances MQ calls try looking at the V7 MQ client. It allows you to load balance across entries of a client table.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| yalmasri |
| Posted: Tue Apr 06, 2010 12:57 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
Thanks for taking the time to read this.
Let me cut down some of the problem statements to make it more readable.1. I have 20 machines with MQ installed on each, and they're all part of a cluster. 3 of those host an application name it A.
2. Clients of application A are deployed on all 20 machines.
3. When a client wants to send messages to application A through MQ, it has to lookup a connection factory and a destination from an LDAP server that's also installed on 2 machines of those 20.
4. Connection factory object stored in LDAP contains a property for queue manager and transport.
5. If I decide to send directly to the queue of any of the 3 instances of application A, Transport has to be set to "Client" and QManager has to be the same as the queue manager's name where my application instances are.
6. If however I made Transport as "Bindings" and QManager equal to local queue manager of the client, then the local queue manager will forward the request to the remote queue manager of any instance of application A. Is there any preference of using one option in points 5 & 6 over the other? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 06, 2010 8:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Now that is a much more clear question...
What it boils down to is more of a synchronous like vs asynchronous approach and also whether you may or may not need multiple phase commit.
Connecting in bindings mode ensures that you can do a multiphase commit at the application level. To do this at the client level you would need to have the Extended Transactional Client installed. Also connecting directly to the processing server will take away the load balancing achieved through the cluster. (V7 allows client load balancing through client table).
Review your requirements. This is ultimately your choice. Remember to factor into your choice your network reliability and connection quality.
A bindings connection using MQ Cluster for load balancing will somewhat even out some of the smallest network problems. Keep in mind that most network problems will affect SLAs.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| yalmasri |
| Posted: Tue Apr 06, 2010 11:27 pm Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| Unfortunately I'm using V6, and efficient load balancing is critical to me. But the problem of defining a connection factory for each machine, then look up the proper one by client is annoying me. Is this the way usually people go about it in bindings mode or I'm inventing something new? |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Apr 07, 2010 3:00 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| yalmasri wrote: |
| Unfortunately I'm using V6, and efficient load balancing is critical to me. But the problem of defining a connection factory for each machine, then look up the proper one by client is annoying me. |
Is it critical to your business - and can the business therefore spend money on a licence for MQ V7, in which this is much easier? Remember MQ V6 goes out of support in a while, so developing a significant new app for it might not be a good choice.
| Quote: |
| Is this the way usually people go about it in bindings mode or I'm inventing something new? |
In "bindings" mode (ie. a server-bound app), you typically connect your app to one single queue manager and rely on it being up. IMHO, YMMV, etc. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 07, 2010 6:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mvic wrote: |
| In "bindings" mode (ie. a server-bound app), you typically connect your app to one single queue manager and rely on it being up. |
Given that if the queue manager isn't up, it's likely the app (running on the same server) probably isn't feeling too well either.
If you need to ensure the queue manager is always available for an app using bindings, buy HA software.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| yalmasri |
| Posted: Wed Apr 07, 2010 7:11 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008
Posts: 110
|
| Quote: |
| If you need to ensure the queue manager is always available for an app using bindings, buy HA software. |
In my case, the clients are nothing but services that receive requests on MQ, so replicating them on more than one QM will do the job. That's simpler than going for an HA software and is as efficient.
I think in V7 (in contrast to V6) you can define a ConnectionFactory without explicit reference to queue manager, and when you look it up, you'll by default be referring to the local one, and that makes going for bindings mode more appealing. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 07, 2010 4:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| yalmasri wrote: |
| Quote: |
| If you need to ensure the queue manager is always available for an app using bindings, buy HA software. |
In my case, the clients are nothing but services that receive requests on MQ, so replicating them on more than one QM will do the job. That's simpler than going for an HA software and is as efficient.
I think in V7 (in contrast to V6) you can define a ConnectionFactory without explicit reference to queue manager, and when you look it up, you'll by default be referring to the local one, and that makes going for bindings mode more appealing. |
You should be able to do that in V6 as well.
Check out the notion of default qmgr. And remember the qmgr needs to be defined as default qmgr on the box...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
