| Author |
Message
|
| bdrummond |
 Posted: Wed Dec 08, 2004 7:34 am Post subject: MC76 on AIX question |
 |
|
Disciple
Joined: 06 May 2004
Posts: 164
|
Hi,
We have 2 full repository QM within the same Cluster that deal with load balancing.
It has become apparent that message sequence needs to be preserved for a particular application. We were thinking along the lines of 'ditching' load balancing in order to preserve message sequence (for this application only) and the MC76 support pac looks to be the best option.
However, this is only available from IBM on Windows platforms.
If the C code could be re-compiled onto AIX, would this solution be supported by IBM..?
Regards. |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Wed Dec 08, 2004 7:51 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Rather simpler than that.
1. Open the output cluster queue from this one application with MQOPEN options set to MQOO_BIND_ON_OPEN, rather than the default MQOO_BIND_AS_Q_DEF. This will cause all msgs put to that Hobj to go to the same instance of the queue in the cluster.
2. Supply the qmgr name in the MQOD passed to the MQOPEN. The msgs put using the returned Hobj will all go to the queue on that qmgr. |
|
| Back to top |
|
|
| bdrummond |
| Posted: Wed Dec 08, 2004 7:56 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
What will happen with this solution if the QM goes down..?
We would like to send all messages through the other QM in this instance. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Dec 08, 2004 8:19 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Use option 1.
When BIND_ON_OPEN is used, the qmgr is initially selected using the same criteria as when BIND_NOT_FIXED is used, but only once when the queue is opened, not for every msg. |
|
| Back to top |
|
|
| bdrummond |
| Posted: Wed Dec 08, 2004 8:29 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
Hi,
Not sure if I'm being unclear or just stupid (most likely the latter).
If the application connects to QM1 with Bind On Open, all messages will be sent to the Clustered Queue on QM1. If QM1 becomes unavailable, will the application automatically send to QM2 or will the application need to be restarted..?
Cheers. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 08, 2004 9:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the application is connected to QM1, and QM1 goes down, you have no more connection. You could either reconnect to QM2, or keep trying QM1 until it comes back up.
If you are using Option 1, then there are no guarantees when you finalyy reestablish a connection that you will bind to the same q as before. But if you explicitly code the Q/QM name on the MQOPEN, then you have control of where the messages go, regradless of when / where you are connected.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Dec 08, 2004 11:33 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
if you are so concerned about what happens when one of the cluster qmgrs goes down, then you should use the clusgter workload exit. The exit is presented with a list of qmgrs which host the queue; the exit returns the number of the qmgr it wants the msg to go to. Part of the data presented to the exit is the qmgr status, so you can determine in the exit whether the qmgr you want to sent the msg to is running.
Now here's one for you.
What if you have decided the destination for the msgs, and the qmgr goes down before you have sent all the msgs? |
|
| Back to top |
|
|
| bdrummond |
| Posted: Thu Jan 13, 2005 3:49 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
|
| Back to top |
|
|
|
|
