| Author |
Message
|
| Shalini |
 Posted: Thu Sep 30, 2004 8:28 am Post subject: Issue while putting the message to Cluster image Queue ????? |
 |
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi All,
We have a critical issue,
We have 3-instance queue manager in three different nodes as a partial Repository connecting to a full repository thro a hub and spoke arch.
The putting application put message to cluster image Queue of partial repository queue manager which in turns reaches the F.R QM cluster queue.
But if the network is down between the Partial (3 QM) and the spoke (Full Repo)queue manager. The image of cluster queue does not disappear from the partial repository. 
Messages get struck into the transmission queue indefinitely till the network comes up, which we cannot afford to.
Is there any way to health check of network and put messages.
Note for single day we expect more than 1 lakh to 1.5 lakhs.
Its not a good idea to ping a channel or check a network for each message put.
Is there a better approach for putting message into the image of cluster queue.
Also problem here is putting application is a third party does not have history or back up of messages before putting to queue.
If we have a solution we will be rerouting it thro other route.
Awaiting your reply
 |
|
| Back to top |
|
 |
| siliconfish |
| Posted: Thu Sep 30, 2004 8:46 am Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
I think the best way to solve your issue is hardware clustering. MQ Clustering will not solve the problem of failover (we can set it though to avaid partial failovers but not completely).
And btw, if your application is soooo critical u cannot afford to have such a weak network that communication between the hub and all the queue manager goes down simultaneously. |
|
| Back to top |
|
|
| Shalini |
| Posted: Thu Sep 30, 2004 9:22 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi Silisonfish,
Thanks for your reply, Is there any other design or prog tasks we can think of other than hardware clustering ???
 |
|
| Back to top |
|
|
| siliconfish |
| Posted: Thu Sep 30, 2004 9:43 am Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
| Can u explain ur current setup? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 30, 2004 9:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Is there any other network link between the two queue managers?
If there is, you may be able to define some manual cluster channels that use the other link.
If there is not, then you can not solve this problem without fixing the network so it does not go down.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Sep 30, 2004 11:49 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| There is a channel attribute BATCHHB (batch heartbeat) which may help in this case. Read upon it in the Command Reference manual. |
|
| Back to top |
|
|
| Shalini |
| Posted: Wed Nov 03, 2004 3:01 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi Nigelg/jefflowrey,
Thanks for reply I gone thro the docs which gave me following details
| Quote: |
Batch Heartbeat Interval (BATCHHB)
The batch heartbeat interval allows a sending channel to verify that the receiving channel is still active just before committing a batch of messages, so that if the receiving channel is not active, the batch can be backed out rather than becoming in-doubt, as would otherwise be the case. By backing out the batch, the messages remain available for processing so they could, for example, be redirected to another channel.
If the sending channel has had a communication from the receiving channel within the batch heartbeat interval, the receiving channel is assumed to be still active,otherwise a ’heartbeat’ is sent to the receiving channel to check.
You can reduce the opportunity for a channel to be placed in doubt by using the Batch Heartbeat channel parameter (BATCHHB). When a value for this parameter is specified, a sender channel checks that the remote channel is still active before taking any further action. If no response is received the receiver channel is considered to be no longer active. The messages can be rolled-back, and re-routed, and the sender-channel is not put in doubt. |
But the problem is that we donot have any alternative channel from Partial repository to Full Repository only one pair of channel.
I belive this approach is also not going to help me.
Can you suggest me diffrent approach
|
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Nov 03, 2004 3:48 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The problem is that your msgs have only a single possible destination in the cluster, so they MUST stay in the cluster xmitq until the channel can be restarted, because the msgs have nowhere else to go. This is designed into your system; you should have thought about this issue (of non-availability) at the design stage, not after the project is running live.
You could define an alternative destination by having another qmgr with the same set of queues, such that if the original qmgr is not available the msgs will be routed to the alternative qmgr. To avoid the msgs being reound-robined between the original and alternative destination, suspend the alternative destination qmgr from the cluster. Suspend is only advisory; msgs will be sent to that qmgr if the only other possible destination has a lower priority. |
|
| Back to top |
|
|
|
|
