| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster - FR and PR |
« View previous topic :: View next topic » |
| Author |
Message
|
| masteringmq |
 Posted: Sat Jan 24, 2009 7:11 am Post subject: Cluster - FR and PR |
 |
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| I came across a reading that says if the FR is down there will be no impact on other QM in the repository. This means that messages can continue to flow to the QM in the cluster. However the QM in the cluster will not receive any updates as the FR is down. As long as no changes is done to the cluster setting there will be no problem. Do you all agree on this?. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Jan 24, 2009 9:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...there will be no problem |
Generally, a loss of one FR will have little or no impact.
However...
If the FR is down, then the FR queue manager is no longer available for MQCONNect from any applications, and therefore can not be the sender or receiver of application messages.
If the other FR in the cluster survives, it will take FR responsibilities for PR queue managers that had the now-failed FR.
If the failed FR is the one and only FR in the cluster (a worst-practice), then existing cluster objects already known to the PRs will continue to behave in the expected way.
No changes? Administrative or application-made? Changes may include non-administrative changes - a cluster queue reaching MAXDEPTH or being PUT(inhibited) by an application. With no FR, these types of changes cannot be propogated around the cluster, and will likely cause otherwise well-behaved applications to misbehave.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 24, 2009 10:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I agree with Bruce, other than the a queue reaching Max Depth being a cluster event. A clustered q filling up on a PR does not send any info to the FR. The other QMs in the cluster will still see that full q as a valid destination, and the messages will spill over into the DLQ as they arrive on that PR QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 24, 2009 10:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I was thinking of bind at MQOPEN time for a cluster queue with multiple instances.
If memory serves (always questionable), at MQOPEN, clustering software looks into the repositories (PR and, if necessary, FR) for available cluster queues. Cluster queues that are put(inhibited) or full or otherwise unavailable are excluded from the candidate list. Alterations like these to a PRs cluster object are shared with the FRs.
An indirect reference to this behavior (about how clusters work) is in the WMQ Clusters manual in a topic describing how to remove a cluster queue from the cluster. I'm paraphrasing here. It says to first wait for applications using the queue to quiesce, then PUT(INHIBIT) the queue. This will cause future MQOPENs to find other instances (if any).
Back to the original post no problem reference. If the FR is only an FR; that is, it hosts no applications, no application queues or xmit queues (behaving like a hub), then there will be little or no impact to the loss of the FR.
Of course, if the failed FR hadn't completed propogating new/updated cluster object messages to the other FR and PRs, then there will likely be problems.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 24, 2009 11:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I correct myself here, and beg forgiveness. I did a quick test.
MAXDEPTH condition does not propogate to the repositories. Future MQOPENs will succeed. Future MQPUTs will succeed, with messages in excess of MAXDEPTH sent to DLQ.
Regarding PUT(INHIBITED), local MQPUT attempts will receive MQRC_PUT_INHIBITED (as usual); remote MQPUT attempts will receive MQRC_CLUSTER_PUT_INHIBITED.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sat Jan 24, 2009 8:32 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Yes I agree that at the application level there will be an impact because if the FR is down then the application cant make a connection. However from a cluster level, if both the FR is down there will be no impact on other QM in the cluster. In other words the other QM in the cluster can continue to function as long as no changes is made to the cluster setting (a cluster queue being PUT(inhibited) by an application). So I can still have applications to connect to the other QM in the cluster. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 24, 2009 9:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
That's why IBM recommends two FRs.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| 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
|
|
|
|
