Author |
Message
|
gurusridhar |
Posted: Tue Dec 02, 2003 12:36 am Post subject: Any example for load balance and failover |
|
|
Newbie
Joined: 19 Nov 2003 Posts: 9 Location: Singapore
|
hi,
Any example for load balance and failover in Java for MQ. |
|
Back to top |
|
 |
GreatG |
Posted: Tue Dec 02, 2003 1:00 am Post subject: |
|
|
 Novice
Joined: 02 Dec 2003 Posts: 13
|
Mean Sample code in Java,
check manual Using Java for WebSphereMQ |
|
Back to top |
|
 |
dtauzell |
Posted: Wed Dec 17, 2008 11:38 am Post subject: |
|
|
Apprentice
Joined: 23 May 2002 Posts: 37
|
I don't have code to give you, but what I did for JBOss/MQ was:
1. Have a way to notify a JMX bean that MQ seems dead
2. JMX bean then removes all JNDI entries for MQ and creates new ones for
a different Queue Manager. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Dec 18, 2008 1:00 am Post subject: Re: Any example for load balance and failover |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
gurusridhar wrote: |
Any example for load balance and failover in Java for MQ. |
Load balancing in WMQ should be done with a cluster. Your application should have no involvement in this (aside from not specifying a specific target).
Failover should be done with HA software (server side) or a client connection table (client side). Again this should not involve your application. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Thu Dec 18, 2008 1:04 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Depends.
I like the MQ client model with multiple threads (and/or multiple servers) accessing the same queues.
Automatic load-balancing and failover with zero effort and no clustering needed. |
|
Back to top |
|
 |
George Carey |
Posted: Thu Dec 18, 2008 2:28 pm Post subject: automatic load balancing |
|
|
Knight
Joined: 29 Jan 2007 Posts: 500 Location: DC
|
I agree think I like the client model better as well ... but where/how does one get the 'automatic' no effort load balancing. Automatic failover I can see with Client Channel tables configured appropriately but "auto" load balancing ? _________________ "Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Dec 18, 2008 11:04 pm Post subject: Re: automatic load balancing |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
George Carey wrote: |
I agree think I like the client model better as well ... but where/how does one get the 'automatic' no effort load balancing. Automatic failover I can see with Client Channel tables configured appropriately but "auto" load balancing ? |
George, auto load balancing on the chl table is a feature from V7. You won't find it on V6.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
George Carey |
Posted: Fri Dec 19, 2008 11:53 am Post subject: V7 |
|
|
Knight
Joined: 29 Jan 2007 Posts: 500 Location: DC
|
Quote: |
auto load balancing on the chl table is a feature from V7. You won't find it on V6 |
Ahh ... I vaguely remember reading something about it ... obviously I'm not using V7 to any extent yet !!!
Well this in another reason to get to it ! ... Thank you for reminder FJ.
Regards,
GTC _________________ "Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
Back to top |
|
 |
zpat |
Posted: Fri Dec 19, 2008 1:04 pm Post subject: Re: automatic load balancing |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
George Carey wrote: |
I agree think I like the client model better as well ... but where/how does one get the 'automatic' no effort load balancing. Automatic failover I can see with Client Channel tables configured appropriately but "auto" load balancing ? |
Simple.
Host the queues on a single queue manager (hardware clustered if you like for resilence).
Host the applications on two or more app servers, using client connections to the queue manager (just the one QM).
Long running (listener style) client apps will pull messages as fast as they can process then (but not faster!).
If one app server fails - the other carries on (anything in flight is rolled by using syncpoint).
No orphaned messages to worry about.
Remember - don't trigger - just use MQGET with WAIT and process the message before getting the next one. Use SYNCPOINT to protect against application failure. |
|
Back to top |
|
 |
George Carey |
Posted: Fri Dec 19, 2008 2:29 pm Post subject: two side of load balancing |
|
|
Knight
Joined: 29 Jan 2007 Posts: 500 Location: DC
|
Well that is the other end of load balancing I guess. I was thinking more on the distribution of the messages in-bound ... and FJ answered that .. RT?M but yours addresses the other side (application processing) load balancing ... a different and useful approach as well.
Your comment about processing the message before doing the next get ... I am assuming you mean to leave the syncpoint uncommitted until processing is completed so that a failure will/would cause a roll back. I will have to read up on JMS to see how that is accomplished in the API ... I don't suppose there is a method as simple as saying MQcommit ... actually I think its session.commit or something like that but that is using JTA if I recall, and then there is container managed bean environment frufru ... yada yada ....
Sorry my growing disdain for 'esoterical software conceptualization and jargonism' is showing. I need to open a pub ... much more sane.
GTC _________________ "Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 19, 2008 2:38 pm Post subject: Re: two side of load balancing |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
George Carey wrote: |
Well that is the other end of load balancing I guess. I was thinking more on the distribution of the messages in-bound ... and FJ answered that .. RT?M but yours addresses the other side (application processing) load balancing ... a different and useful approach as well.
Your comment about processing the message before doing the next get ... I am assuming you mean to leave the syncpoint uncommitted until processing is completed so that a failure will/would cause a roll back. I will have to read up on JMS to see how that is accomplished in the API ... I don't suppose there is a method as simple as saying MQcommit ... actually I think its session.commit or something like that but that is using JTA if I recall, and then there is container managed bean environment frufru ... yada yada ....
Sorry my growing disdain for 'esoterical software conceptualization and jargonism' is showing. I need to open a pub ... much more sane.
GTC |
George you memory serves you well.
You do have transaction processing rolled into the session with JMS.
In stand alone processing make sure you mark the session as transacted and you issue the session.commit().
In server processing most of this is handled by the deployment descriptor, and container managed.
The odd case has bean managed transactions... Those are always to look at in a case by case basis, often suspend the global transaction, if it exists, and absolutely need to resume it before giving back control (need for a finally block).
Have fun.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zpat |
Posted: Sat Dec 20, 2008 3:00 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
JMS uses syncpoint automatically on transacted sessions. |
|
Back to top |
|
 |
|