| Author |
Message
|
| careboy |
 Posted: Tue Aug 15, 2006 5:08 am Post subject: Java Input Node - any contention in getting messages? |
 |
|
Novice
Joined: 15 Jan 2006
Posts: 10
|
I intend to have my broker (v5) process messages from a queue residing at a remote queue manager. To achieve this, i intend to use a Java Input Node to transfer the message to over to my broker.
Question:
The remote queue is also an input queue for another message broker.
1. How do i ensure that there would be no contention to get the message from the remote queue?
2. How do i ensure that the message is not duplicated across 2 brokers?
Any advice is appreciated. Thanks. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Aug 15, 2006 5:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No.
This is entirely wrong.
Don't do this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| careboy |
| Posted: Tue Aug 15, 2006 6:19 am Post subject: |
|
|
Novice
Joined: 15 Jan 2006
Posts: 10
|
hi,
The intention is to have something like shared queue on MQ zOS. We know the java input node is definitely not as efficient as MQInputNode.
We need to do this for a HA setup, where 2 brokers residing on 2 Qmgrs, and we need to share the input queue to other broker qmgr.
Hope is clear.
-CareBoy |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 15, 2006 6:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is not HA.
This is an entirely wrong thing to do.
If you need shared queues, then you need to pay for z/OS and a sysplex to run a queue sharing group.
If the value of that is not worth the cost, then... guess what... you don't need shared queues and can live with messages being orphaned on a downed queue manager for some period of time.
A proper configuration for good HA on a distributed platform looks like this.
1) Two brokers, each with their own queue manager
2) Both queue managers in an MQ Cluster
3) Each broker and queue manager in an HA failover configuration to some other machine
Messages being given to the broker are load balanced by the clustering. Each queue manager is highly available due to HA failover, and consequently each broker is highly available. Messages given to a particular broker are only unprocessable while the broker/qmgr is being failed over.
Any attempts on your part to implement your own HA mechanisms are almost certainly a) a duplication of effort that has already been done by professional HA software developers (like ServiceGuard or HACMP or etc.), b) likely to increase the risk of failure and therefore is a waste of time and money.
If, for whatever reason your management decides to go ahead with allowing this increased risk for no real gain - then at least don't bother writing the JCN yourself. Use the MQGetAny support pack.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| careboy |
| Posted: Tue Aug 15, 2006 9:43 am Post subject: |
|
|
Novice
Joined: 15 Jan 2006
Posts: 10
|
>>Messages being given to the broker are load balanced by the >>clustering.
We will use MQcluster for both brokers, to ensure better broker availability.
>> Each queue manager is highly available due to HA failover, and >>consequently each broker is highly available.
>>Messages given to a >>particular broker are only unprocessable while the broker/qmgr is >>being failed over.
In this event, this is what we need, a java input node that can retrieve the failure broker input message, so that the processing of messages will not be stopped.
We understand having sysplex on zOs is the ideal solution, but not every customer can afford the cost.
I am not setting an HA environment, we are trying to increase the broker availability with MQcluster, and this java input node. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 15, 2006 9:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you configure the two brokers I described in a proper HA failover configuration, then the period of time in which messages that have a) been sent to the queue manager already AND b) not been processed will be unavailable will be exactly as long as it takes for the HA subsystem to stop one broker and start it on the backup machine.
On average, this is between ten and twenty minutes. I know some people who have been able to get this time to about 1 minute - with a very particular kind of configuration.
During this timeframe, all new messages will be directed to the other broker, and processed normally.
So at no point is ALL processing of messages stopped.
With a bit of care, you can ensure that the smallest possible number of messages will be stranded on the queue manager during it's failover.
And if the queue manager is down on the other machine, your Java node won't be able to get at it's messages no matter what. All you are really doing is implementing your own load balancing scheme!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 15, 2006 11:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| careboy wrote: |
In this event, this is what we need, a java input node that can retrieve the failure broker input message, so that the processing of messages will not be stopped.
|
Okay, so QM1 fails / crashes / is brought down by a hardware failure. You have QM2 to pick up the load from the gateway via the cluster and it's all good.
You (as I understand it) want to use a Java Input Node running on QM2 to retrieve the stranded messages from QM1 so processing is not interupted. How is this node connecting if QM1 is flat on it's back? 
Once you've restored QM1 (in between 1 and 20 minutes as indicated) these messages will be processed by QM1 before QM2 can get a look in.
What am I missing in your design? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
