Re: Clustering Question
Title: Message Hi Tony, Have you considered adding clustered aliases to your TEST.QUEUE's, e.g. PARTICULAR.TEST.QUEUE. That way your consumers canget their messages from a single queue, even when the producer wanted a particular destination. It also gives you the option of scaling up a location or region's resources by having multiple aliases with the same name. You also get the opportunity of naming the aliases with qualifiers that are meaningful in business terms, rather than MQ admin terms. It is also clean JMS. Alan -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T RobSent: 29 November 2004 17:29To: [EMAIL PROTECTED]Subject: Re: Clustering Question Funny but we just had this conversation in our team meeting today except it was about JMS and Pub/Sub. My colleague was explaining that JMS requires a one-to-one correspondence between JNDI managed objects and potential destinations.So a cluster queue defined in JNDIis known to JMS as a single destination, no matter how many instances of the queue exist. OR...you can have a different JNDI object for each combination of QMgr/Queue, even though the queues all have the same name. What you cannot do, apparently, is open a JNDI object and dynamically specify the QMgr part of the destination because "QMgr" is an MQ constructis not part of the JMS spec. So if my colleague is correct (and we are still pretty new to JMS over here so I'll be the first to admit this may be a much deeper issue), you either need to create a separateJNDI object for each possible destination queue, or use a solution that is not pure JMS. I'll be interested to see if anyone else has a solution that works within JMS and does not require all the JNDI objectsbecause it might help us with our Pub/Sub problem. -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:44 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Sorry, I made a poor assumption, I should know better. We may do it differently than Tony has in mind. Our online app is on the WAS server and we always connect to the same QMGR with JMS. Then based on customer number, or some other factor that determines where an order is filled we send the Queue messages to the correct queue. It is at that point we require a unique queue name as any reference to the receiving queue manager name in the message header will, no can but will, cause the 2085 error message. I don't understand your reference to round robining as the original question asked about sending a message to a unique queue. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT)Sent: Monday, November 29, 2004 10:24 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one que
Clustering Question
Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED]
Re: Clustering Question
Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.Allison Sent: Monday, November 29, 2004 9:53 AM To: [EMAIL PROTECTED] Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components: 1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED]
Re: Clustering Question
You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Clustering Question
Alan, Found this information out off of MQSeries.net http://www.mqseries.net/phpBB2/viewtopic.php?t=12350highlight=object It appears that it can be done without the dreaded 2085. Thanks for your input Tony From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, AlanSent: Monday, November 29, 2004 10:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED]
Re: Clustering Question
All, In this case these queues should have a null cluster nameattribute. Ò¿ÓBob JuchCitigroupMQ Mainframe Support TeamWeehawken, NJ201-974-2147mailto:[EMAIL PROTECTED] -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Monday, November 29, 2004 11:24 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Clustering Question
Sorry, I made a poor assumption, I should know better. We may do it differently than Tony has in mind. Our online app is on the WAS server and we always connect to the same QMGR with JMS. Then based on customer number, or some other factor that determines where an order is filled we send the Queue messages to the correct queue. It is at that point we require a unique queue name as any reference to the receiving queue manager name in the message header will, no can but will, cause the 2085 error message. I dont understand your reference to round robining as the original question asked about sending a message to a unique queue. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT) Sent: Monday, November 29, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, Alan Sent: Monday, November 29, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.Allison Sent: Monday, November 29, 2004 9:53 AM To: [EMAIL PROTECTED] Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components: 1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-3740 Cell Phone (612) 306-0487 E-Mail: [EMAIL PROTECTED] This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Clustering Question
Funny but we just had this conversation in our team meeting today except it was about JMS and Pub/Sub. My colleague was explaining that JMS requires a one-to-one correspondence between JNDI managed objects and potential destinations.So a cluster queue defined in JNDIis known to JMS as a single destination, no matter how many instances of the queue exist. OR...you can have a different JNDI object for each combination of QMgr/Queue, even though the queues all have the same name. What you cannot do, apparently, is open a JNDI object and dynamically specify the QMgr part of the destination because "QMgr" is an MQ constructis not part of the JMS spec. So if my colleague is correct (and we are still pretty new to JMS over here so I'll be the first to admit this may be a much deeper issue), you either need to create a separateJNDI object for each possible destination queue, or use a solution that is not pure JMS. I'll be interested to see if anyone else has a solution that works within JMS and does not require all the JNDI objectsbecause it might help us with our Pub/Sub problem. -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:44 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Sorry, I made a poor assumption, I should know better. We may do it differently than Tony has in mind. Our online app is on the WAS server and we always connect to the same QMGR with JMS. Then based on customer number, or some other factor that determines where an order is filled we send the Queue messages to the correct queue. It is at that point we require a unique queue name as any reference to the receiving queue manager name in the message header will, no can but will, cause the 2085 error message. I dont understand your reference to round robining as the original question asked about sending a message to a unique queue. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT)Sent: Monday, November 29, 2004 10:24 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question You should use the QMGR name attribute of the queue object, and populate it with the name of a QM in the cluster that does host the queue. If you choose a QM that does not have the queue, you will get the 2085. If you populate it with the local QM name, you lose round robining if the local QM hosts that queue, or 2085 if it does not. You don't need to make different q names on all your clustered QMs. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Bender, AlanSent: Monday, November 29, 2004 11:17 AMTo: [EMAIL PROTECTED]Subject: Re: Clustering Question Tony, We have an application running with the same component versions. You must remember that in a cluster containing multiple copies of the same Queue name the cluster will load balance. We have also noted that with the JMS client connection if the QMGR name is used in the JMS configuration we get the dreaded 2085 error code MQRC_UNKNOWN_OBJECT_NAME. What we have done is to append the Queue name with the, in our case, division number. (example: TEST.QUEUE.012). That way you have a unique queue. This may seem simplistic but it does work. Alan From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony.AllisonSent: Monday, November 29, 2004 9:53 AMTo: [EMAIL PROTECTED]Subject: Clustering Question Good morning everyone... I think I am having a brain meltdown Here is what we are trying to accomplish. Components:1. WAS 5.1 2. Websphere MQ 5.3.0.8 1370 queue managers in single cluster. WAS application running with client connection to central queue manager needs to send a single message to one queue manager in the cluster. (There are 1364 instances of for example (TEST.QUEUE) One on each of the queue managers in the cluster. The queue managers are broken down into two categories (HQ and Stores) all stores queue managers are distributed across the country and each have a unique name. My question is, How can my local HQ application running on WAS put a message to a specific queue manager within the cluster? I know each MQ object has a unique name (Object Name / Object QMGR Name) Where in the JMS code can we put the specific name? Thanks for any input you can provide. Thanks Tony Allison Technical Architect Target Technology Services Enterprise Tools / Middleware 33 South 6th Street 11th Floor / Cube 11240 Minneapolis, MN Direct (612) 304-374
Re: MQ Clustering Question
At the 'Application' level means the server in my scenario. What I am trying to achieve is this: If a back-end service running on a server is knocked out of the rotation (even though MQ might be OK), I want to: 1. Not send anymore messages to that instance (from the client) 2. Move the stuck message on that instance to another instance that is being serviced. I cannot afford for messages to get stuck for any period of time. PS: If a cluster queue is set to PUT(INHIBITED), on the server, will the WLM exit that IBM supplies recognize it when the client does the MQPUT (assume DEFBIND is NOT-FIXED)? Or, will the message travel down the channel to the cluster queue instance that was chosen, then the MCA will detect it when it tries to put the message to the chosen cluster queue? I know it will reroute it to another instance of the cluster queue, if one exist. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Clustering Question
If you set the cluster queue to PUT(INHIBIT) then that information is fed back to the originating systems and the default WLM will no longer choose you as a target (unless it has to if I recall). Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 18/10/2004 14:48:29: At the 'Application' level means the server in my scenario. What I am trying to achieve is this: If a back-end service running on a server is knocked out of the rotation (even though MQ might be OK), I want to: 1. Not send anymore messages to that instance (from the client) 2. Move the stuck message on that instance to another instance that is being serviced. I cannot afford for messages to get stuck for any period of time. PS: If a cluster queue is set to PUT(INHIBITED), on the server, will the WLM exit that IBM supplies recognize it when the client does the MQPUT (assume DEFBIND is NOT-FIXED)? Or, will the message travel down the channel to the cluster queue instance that was chosen, then the MCA will detect it when it tries to put the message to the chosen cluster queue? I know it will reroute it to another instance of the cluster queue, if one exist. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Clustering Question
Yes, if it is inhibited, messages will not be routed there, unless they were specifically destined for that particular QM (the sending app specified the destination QM, or snuck in a Bind On Open MQOPEN before you inhibited it), or if it is the only Q in the cluster by that name. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Paul Clarke Sent: Monday, October 18, 2004 10:13 AM To: [EMAIL PROTECTED] Subject: Re: MQ Clustering Question If you set the cluster queue to PUT(INHIBIT) then that information is fed back to the originating systems and the default WLM will no longer choose you as a target (unless it has to if I recall). Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 18/10/2004 14:48:29: At the 'Application' level means the server in my scenario. What I am trying to achieve is this: If a back-end service running on a server is knocked out of the rotation (even though MQ might be OK), I want to: 1. Not send anymore messages to that instance (from the client) 2. Move the stuck message on that instance to another instance that is being serviced. I cannot afford for messages to get stuck for any period of time. PS: If a cluster queue is set to PUT(INHIBITED), on the server, will the WLM exit that IBM supplies recognize it when the client does the MQPUT (assume DEFBIND is NOT-FIXED)? Or, will the message travel down the channel to the cluster queue instance that was chosen, then the MCA will detect it when it tries to put the message to the chosen cluster queue? I know it will reroute it to another instance of the cluster queue, if one exist. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Clustering Question
When you say 'at the application level' do you mean at the client end or at the server end ? Why is setting PUT(INHIBIT) on the cluster queue not good enough ? This will cause the cluster to only send messages to the remaining cluster queues that aren't PUT(INHIBIT)'ed. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley MQSeries List [EMAIL PROTECTED] wrote on 15/10/2004 18:00:10: Thanks for answers to my prior question, especially Paul Clarke from IBM. I will definitely test out your suggestion Background In a cluster I can have cluster queues with the same name on multiple cluster queue managers. I need a way (at the application level) to NOT send messages to a specific cluster queue if the application servicing that instance dies/stops running etc. I don't want to write an exit. Question: Has anyone developed an elegant solution to this problem and would care to share it, on-line or off-line? My application cannot tolerate stuck messages. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Clustering Question
Thanks for answers to my prior question, especially Paul Clarke from IBM. I will definitely test out your suggestion Background In a cluster I can have cluster queues with the same name on multiple cluster queue managers. I need a way (at the application level) to NOT send messages to a specific cluster queue if the application servicing that instance dies/stops running etc. I don't want to write an exit. Question: Has anyone developed an elegant solution to this problem and would care to share it, on-line or off-line? My application cannot tolerate stuck messages. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Clustering Question
In a nutshell, we will be allowing an outside firm access to put to a few internal queue managers. In order to achieve some method of workload balancing, we wanted to use MQ's clustering capabilities. First of all, what are the drawbacks of just making one big cluster (external and internal queue managers in the same cluster) as opposed to having a gateway queue manager in overlapping clusters (which is recommended from one document that I've read). Aside from issues with server connection channels, what other security issues should we be concerned with, and how would those issues be addressed? -Warren Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Clustering Question
It's not just your server connection channels you have to watch! As the external QMs will be connecting over the Extranet, how do you KNOW that they are who they claim to be and how are you going to ensure that other QMs don't join the cluster, or just connect to regular channels on your QMs now that you've opened the firewall for MQ traffic. If I'm Mr Evil Hacker and know the name and listener port for one of your cluster repositories, I can attach my QM to your cluster pretty sharply and put all sorts of messages to all sorts of queues, the possibilities are quite drool making for the bad guy. Lets see what I can think of quickly: Put interesting messages to SYSTEM.COMMAND.QUEUE on your QMs Find some interesting clusters queues and put some messages to them - you never know I might find a SWIFT queue and put some SWIFT format messages on there to pay me lots of ??. Fill up your cluster queues with invalid messages causing interesting Denial of Service problems. You can protect against most of this with a product like Data Secure for MQ, and to a lesser extent using SSL. HTH Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Warren Sent: 10 February 2004 16:21 To: [EMAIL PROTECTED] Subject: Clustering Question In a nutshell, we will be allowing an outside firm access to put to a few internal queue managers. In order to achieve some method of workload balancing, we wanted to use MQ's clustering capabilities. First of all, what are the drawbacks of just making one big cluster (external and internal queue managers in the same cluster) as opposed to having a gateway queue manager in overlapping clusters (which is recommended from one document that I've read). Aside from issues with server connection channels, what other security issues should we be concerned with, and how would those issues be addressed? -Warren Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Clustering Question
what are the drawbacks of just making one big cluster (external and internal queue managers in the same cluster) as opposed to having a gateway queue manager in overlapping clusters (which is recommended from one document that I've read). Your firewall administration can get unwieldy. Rather than setting up a couple rules on the firewall, you now have to allow for the possibility of however many external QMgrs connecting to some number of internal QMgrs. So if you have three internal QMgrs talking to two external QMgrs you will need 6 sets of rules. You will also need to set up the firewall with no address translation among all the related hosts. When you set up a CLUSRCVR channel, both the external hosts and the internal hosts (the repositories at the very least) need to access it using the same IP address. Aside from issues with server connection channels, what other security issues should we be concerned with, and how would those issues be addressed? An MQ cluster is basically a Pub/Sub engine feeding a modified Command Server. When you advertise a queue or join a cluster, the configuration change is published to the repositories and propagated to anyone subscribed to those changes. When the published changes arrive at a repository or subscribing QMgr they are acted on by the modified Command Server which then builds channels or updates the local repository (whether full or partial). From a security standpoint, you should be aware that any member of the cluster can publish these messages and your QMgrs will automatically respond. That means any QMgr which can join the cluster can become a full repository and/or alter the cluster's configuration. Also, any QMgr which can join the cluster can send messages anywhere throughout the cluster, whether the target queues are advertised to the cluster or not. So if your QMgrA is in the cluster I can send PCF messages to [EMAIL PROTECTED] and because they arrive over your CLUSRCVR channel, chances are they have full mqm admin privileges. Since the attacker can be a repository, they generally know enough about your cluster to go at least one hop beyond the cluster further into your MQ network. The gateway is meant to restrict that one-hop access to just the QMgrs the other side needs to know about. Remove the gateway and the one-hop now extends considerably further in. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Clustering question regarding communications (MQ 5.3 on z/OS 1.2)
I've come across an issue regarding the CONNAME that is made 'public' in the CLUSRCVR definition. As you all know, the value will be stored in the repositories and used by any qmgr's joining the cluster to create an auto-defined CLUSSDR channel as needed. We have internal (inside of our firewall) qmgrs in the cluster, as well as external (outside of our firewall) qmgrs in the cluster. Here's my concern: The IP address specified in the CONNAME of the CLUSRCVR definition needs to serve: qmgrs inside the firewall, who use an internal un'NAT'd address AND qmgrs outside of the firewall who need to use an external NAT'd address In a nutshell, I have one place to specify 2 addresses. I know using the DNS name would be a possible remedy, however, certain external clients are reluctant to use the DNS name - they require an actual IP address. I'm assuming someone else has run into this scenario - clustering with qmgrs in the cluster that are internal and external... Thanks in advance. Mike Davidson TSYS MQ Tech Support [EMAIL PROTECTED] The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Clustering question regarding communications (MQ 5.3 on z/OS 1.2)
Mike, Since we don't have a really good cluster channel exit, we don't let external vendors into our main cluster. Too much ability to send cluster definitions down the pipeline and get them implemented automagically. We also don't like to setup a firewall rule that allows them to access multiple QMgrs on our side. Tootough to have to harden all those QMgrs. Instead, we set them upwith point-to-point channelsto a gateway server that is in the cluster but does not house the cluster queues. A cluster alias then insures the messages get round-robined as expected. But if you are going to play with clusters through the firewall, whatever you use in the CONNAME MUST resolve on both sides. -- T.Rob -Original Message-From: Mike Davidson [mailto:[EMAIL PROTECTED]Sent: Friday, January 23, 2004 1:09 PMTo: [EMAIL PROTECTED]Subject: Clustering question regarding communications (MQ 5.3 on z/OS 1.2)I've come across an issue regarding the CONNAME that is made 'public' in the CLUSRCVR definition. As you all know, the value will be stored in the repositories and used by any qmgr's joining the cluster to create an auto-defined CLUSSDR channel as needed. We have internal (inside of our firewall) qmgrs in the cluster, as well as external (outside of our firewall) qmgrs in the cluster. Here's my concern: The IP address specified in the CONNAME of the CLUSRCVR definition needs to serve: qmgrs inside the firewall, who use an internal un'NAT'd address AND qmgrs outside of the firewall who need to use an external NAT'd address In a nutshell, I have one place to specify 2 addresses. I know using the DNS name would be a possible remedy, however, certain external clients are reluctant to use the DNS name - they require an actual IP address. I'm assuming someone else has run into this scenario - clustering with qmgrs in the cluster that are internal and external... Thanks in advance. Mike DavidsonTSYS MQ Tech Support[EMAIL PROTECTED] The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Quick clustering question...
Has anybody out there successfully implemented MQ clustering in a high volume production environment? Mainframe and/or distributed. If so, has your experience been positive? The feeling here right now is that it is more trouble than it's worth, and is not quite ready for prime time. I'm still on the positive side, but support is dwindling. Mark This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Quick clustering question...
We've been using it for nearly two years now. Our largest cluster consists of about 20 queue managers mostly distributed. We move 100's of gigs of data per day and have never lost a byte. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: Quick clustering question... Has anybody out there successfully implemented MQ clustering in a high volume production environment? Mainframe and/or distributed. If so, has your experience been positive? The feeling here right now is that it is more trouble than it's worth, and is not quite ready for prime time. I'm still on the positive side, but support is dwindling. Mark This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Quick clustering question...
It has been my experience that clustering, though troublesome in earlier releases, has become a very stable component of MQSeries. We are using clustering in several of our environments and have not had much trouble at all since we moved to MQSeries 5.2. We are not, however, operating anywhere near what most would consider high-volume, so I'm not sure how much this helps. I suggest you put together a demo environment and bang on it. [EMAIL PROTECTED] wrote: Has anybody out there successfully implemented MQ clustering in a highvolume production environment? Mainframe and/or distributed. If so, hasyour experience been positive?The feeling here right now is that it is more trouble than it's worth, andis not quite "ready for prime time". I'm still on the positive side, butsupport is dwindling.MarkThis transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.Instructions for managing y our mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveDo You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs
Re: Quick clustering question...
Thanks - that helps Chuck Brasfield [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 08/13/2002 01:11:20 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Quick clustering question... This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Quick clustering question...
Dave - Great to hear it. I don't know what the proper etiquette here is, but would you mind conferencing with some folks around here? I should probably try to arrange that through IBM with your permission. What do you think? I can't imagine there is too much conflict of interest between Marriott and Bank One. Mark De Seve, David [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 08/13/2002 01:03:33 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Quick clustering question... We've been using it for nearly two years now. Our largest cluster consists of about 20 queue managers mostly distributed. We move 100's of gigs of data per day and have never lost a byte. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: Quick clustering question... Has anybody out there successfully implemented MQ clustering in a high volume production environment? Mainframe and/or distributed. If so, has your experience been positive? The feeling here right now is that it is more trouble than it's worth, and is not quite ready for prime time. I'm still on the positive side, but support is dwindling. Mark This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive