Re: Failover Logic to secondary QM in JAVA
But I also need to trap connection related errors on the MQOPEN, MQPUT1, MQPUT and MQGET. While quite rare, it is possible I MQCONN successfully, only to have the QM become unavailable before I can do my open and put/get. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: GIES, STEVE [mailto:STEGIE@;SAFECO.COM] Sent: Thursday, October 24, 2002 7:12 PM To: [EMAIL PROTECTED] Subject: Re: Failover Logic to secondary QM in JAVA Peter - You might want to consider your question from the other angle - what reason codes, returned from the MQCONN call, are acceptable to use the queue manager you are attempting to connect to. The answer, of course, is (MQRC-NONE) and possibly 2002 (MQRC-ALREADY-CONNECTED). In all other cases you will not get back a valid hConn so you cannot use this queue manager. That's the time to try the secondary queue manager. - Steve Gies -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:Peter.Potkay@;THEHARTFORD.COM] Sent: Wednesday, October 23, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: Failover Logic to secondary QM in JAVA I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 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: Failover Logic to secondary QM in JAVA
Peter - You might want to consider your question from the other angle - what reason codes, returned from the MQCONN call, are acceptable to use the queue manager you are attempting to connect to. The answer, of course, is (MQRC-NONE) and possibly 2002 (MQRC-ALREADY-CONNECTED). In all other cases you will not get back a valid hConn so you cannot use this queue manager. That's the time to try the secondary queue manager. - Steve Gies -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:Peter.Potkay@;THEHARTFORD.COM] Sent: Wednesday, October 23, 2002 11:01 AM To: [EMAIL PROTECTED] Subject: Failover Logic to secondary QM in JAVA I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 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: Failover Logic to secondary QM in JAVA
OK. Then lets settle on high availability. I have already used clustering for failover by having three servers with three queue managers in three different sites 200 miles apart. Missed the Java part. As far as the client channel table is concerned, I feel it depends on the application. Any way thanks for discussion. Cheers, -Original Message- From: MQSeries List [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of Stefan Sievert Sent: Wednesday, October 23, 2002 7:36 PM To: [EMAIL PROTECTED] Subject: Re: Failover Logic to secondary QM in JAVA Hi, frankly, MQ clustering doesn't really provide failover, that is one of the common misconceptions about it. If you have a client (or server bindings program) connected to a clustered queue manager and that qmgr fails, than your program will not be automagically reconnected to another qmgr in the cluster. The client channel table approach only works during the initial connect. Once you are connected to the first available queue manager and that connection breaks, you have to provide application code to failover. But I think the main point for Peter is, that he is using Java, which has no access to a channel table in the first place. Plus, the failover code he's intending to write might not be client specific, but should also run in bindings mode. So, Peter, to reply to your question: I think the list of options you mention seem to be complete to cover all failover scenarios. Unless you want to react to other failure situations, like a log/disk full condition or the like, that is. Hope this helps, Stefan >From: MQSeries <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Failover Logic to secondary QM in JAVA >Date: Wed, 23 Oct 2002 19:02:26 -0500 > >Peter, > >I am little confused on why you want to write something that MQSeries >does already for you. ( perhaps I am not understanding your exact >requirement). If you want failover then clustering is already >available. You can also have limited failover by using a client channel >table that contains connections to several queue managers. As I stated >earlier, perhaps I do not understand your requirements. > >Cheers > >-Original Message- >From: MQSeries List [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of >Potkay, Peter M (PLC, IT) >Sent: Wednesday, October 23, 2002 1:01 PM >To: [EMAIL PROTECTED] >Subject: Failover Logic to secondary QM in JAVA > > >I am trying to code some logic that will automatically attempt to >connect to a secondary server/queue manager should the first become >unavailable. The question is, what error codes should this method check >for that would indicate a queue manager being unavailable? > >So far, I think >2009 (MQRC_CONNECTION_ERROR), >2059 (MQRC_Q_MGR_NOT_AVAILABLE), >2161 (MQRC_Q_MGR_QUIESCING), >2162 (MQRC_Q_MGR_STOPPING) > >will cover it. Am I missing any that should be added to this method? > > > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] X 77906 > > > >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 > >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 _ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp 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: Failover Logic to secondary QM in JAVA
Francois, the Java classes for MQ use the MQEnvironment class to define the connection target. Excerpt from 'MQSeries using Java': When MQSeries classes for Java is used as a client, it is similar to the MQSeries C client, but has the following differences: - It supports only TCP/IP. - It does not support connection tables. - It does not read any MQSeries environment variables at startup. - Information that would be stored in a channel definition and in environment variables is stored in a class called MQEnvironment. Alternatively, this information can be passed as parameters when the connection is made. - Error and exception conditions are written to a log specified in the MQException class. The default error destination is the Java console. Stefan From: f turen <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Failover Logic to secondary QM in JAVA Date: Thu, 24 Oct 2002 09:30:52 -0700 Stefan: >But I think the main point for Peter is, that he is using Java, which > has no access to a channel table in the first place If the Java program is running on the client machine why can t it access the channel table? I did not know that there was a difference between Java client program and other client programs. Can you clarify that please? Thanks Francois --- Stefan Sievert <[EMAIL PROTECTED]> wrote: > Hi, > frankly, MQ clustering doesn't really provide > failover, that is one of the > common misconceptions about it. If you have a client > (or server bindings > program) connected to a clustered queue manager and > that qmgr fails, than > your program will not be automagically reconnected > to another qmgr in the > cluster. > The client channel table approach only works during > the initial connect. > Once you are connected to the first available queue > manager and that > connection breaks, you have to provide application > code to failover. > But I think the main point for Peter is, that he is > using Java, which has no > access to a channel table in the first place. Plus, > the failover code he's > intending to write might not be client specific, but > should also run in > bindings mode. > > So, Peter, to reply to your question: I think the > list of options you > mention seem to be complete to cover all failover > scenarios. Unless you want > to react to other failure situations, like a > log/disk full condition or the > like, that is. > > Hope this helps, > Stefan > > >From: MQSeries <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Failover Logic to secondary QM in JAVA > >Date: Wed, 23 Oct 2002 19:02:26 -0500 > > > >Peter, > > > >I am little confused on why you want to write > something that MQSeries > >does already for you. ( perhaps I am not > understanding your exact > >requirement). If you want failover then clustering > is already available. > >You can also have limited failover by using a > client channel table that > >contains connections to several queue managers. As > I stated earlier, > >perhaps I do not understand your requirements. > > > >Cheers > > > >-Original Message- > >From: MQSeries List > [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of > >Potkay, Peter M (PLC, IT) > >Sent: Wednesday, October 23, 2002 1:01 PM > >To: [EMAIL PROTECTED] > >Subject: Failover Logic to secondary QM in JAVA > > > > > >I am trying to code some logic that will > automatically attempt to > >connect to a secondary server/queue manager should > the first become > >unavailable. The question is, what error codes > should this method check > >for that would indicate a queue manager being > unavailable? > > > >So far, I think > >2009 (MQRC_CONNECTION_ERROR), > >2059 (MQRC_Q_MGR_NOT_AVAILABLE), > >2161 (MQRC_Q_MGR_QUIESCING), > >2162 (MQRC_Q_MGR_STOPPING) > > > >will cover it. Am I missing any that should be > added to this method? > > > > > > > >Peter Potkay > >IBM MQSeries Certified Specialist, Developer > >[EMAIL PROTECTED] X 77906 > > > > > > > >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 co
Re: Failover Logic to secondary QM in JAVA
Stefan: >But I think the main point for Peter is, that he is using Java, which > has no access to a channel table in the first place If the Java program is running on the client machine why can t it access the channel table? I did not know that there was a difference between Java client program and other client programs. Can you clarify that please? Thanks Francois --- Stefan Sievert <[EMAIL PROTECTED]> wrote: > Hi, > frankly, MQ clustering doesn't really provide > failover, that is one of the > common misconceptions about it. If you have a client > (or server bindings > program) connected to a clustered queue manager and > that qmgr fails, than > your program will not be automagically reconnected > to another qmgr in the > cluster. > The client channel table approach only works during > the initial connect. > Once you are connected to the first available queue > manager and that > connection breaks, you have to provide application > code to failover. > But I think the main point for Peter is, that he is > using Java, which has no > access to a channel table in the first place. Plus, > the failover code he's > intending to write might not be client specific, but > should also run in > bindings mode. > > So, Peter, to reply to your question: I think the > list of options you > mention seem to be complete to cover all failover > scenarios. Unless you want > to react to other failure situations, like a > log/disk full condition or the > like, that is. > > Hope this helps, > Stefan > > >From: MQSeries <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Failover Logic to secondary QM in JAVA > >Date: Wed, 23 Oct 2002 19:02:26 -0500 > > > >Peter, > > > >I am little confused on why you want to write > something that MQSeries > >does already for you. ( perhaps I am not > understanding your exact > >requirement). If you want failover then clustering > is already available. > >You can also have limited failover by using a > client channel table that > >contains connections to several queue managers. As > I stated earlier, > >perhaps I do not understand your requirements. > > > >Cheers > > > >-Original Message- > >From: MQSeries List > [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of > >Potkay, Peter M (PLC, IT) > >Sent: Wednesday, October 23, 2002 1:01 PM > >To: [EMAIL PROTECTED] > >Subject: Failover Logic to secondary QM in JAVA > > > > > >I am trying to code some logic that will > automatically attempt to > >connect to a secondary server/queue manager should > the first become > >unavailable. The question is, what error codes > should this method check > >for that would indicate a queue manager being > unavailable? > > > >So far, I think > >2009 (MQRC_CONNECTION_ERROR), > >2059 (MQRC_Q_MGR_NOT_AVAILABLE), > >2161 (MQRC_Q_MGR_QUIESCING), > >2162 (MQRC_Q_MGR_STOPPING) > > > >will cover it. Am I missing any that should be > added to this method? > > > > > > > >Peter Potkay > >IBM MQSeries Certified Specialist, Developer > >[EMAIL PROTECTED] X 77906 > > > > > > > >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 > > > >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 > > > _ > Get a speedy connection with MSN Broadband. Join > now! > http://resourcecenter.msn.com/access/plans/freeactivation.asp > > 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 __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ 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: Failover Logic to secondary QM in JAVA
Hi, frankly, MQ clustering doesn't really provide failover, that is one of the common misconceptions about it. If you have a client (or server bindings program) connected to a clustered queue manager and that qmgr fails, than your program will not be automagically reconnected to another qmgr in the cluster. The client channel table approach only works during the initial connect. Once you are connected to the first available queue manager and that connection breaks, you have to provide application code to failover. But I think the main point for Peter is, that he is using Java, which has no access to a channel table in the first place. Plus, the failover code he's intending to write might not be client specific, but should also run in bindings mode. So, Peter, to reply to your question: I think the list of options you mention seem to be complete to cover all failover scenarios. Unless you want to react to other failure situations, like a log/disk full condition or the like, that is. Hope this helps, Stefan From: MQSeries <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Failover Logic to secondary QM in JAVA Date: Wed, 23 Oct 2002 19:02:26 -0500 Peter, I am little confused on why you want to write something that MQSeries does already for you. ( perhaps I am not understanding your exact requirement). If you want failover then clustering is already available. You can also have limited failover by using a client channel table that contains connections to several queue managers. As I stated earlier, perhaps I do not understand your requirements. Cheers -Original Message- From: MQSeries List [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, October 23, 2002 1:01 PM To: [EMAIL PROTECTED] Subject: Failover Logic to secondary QM in JAVA I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 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 _ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp 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: Failover Logic to secondary QM in JAVA
Peter, I am little confused on why you want to write something that MQSeries does already for you. ( perhaps I am not understanding your exact requirement). If you want failover then clustering is already available. You can also have limited failover by using a client channel table that contains connections to several queue managers. As I stated earlier, perhaps I do not understand your requirements. Cheers -Original Message- From: MQSeries List [mailto:MQSERIES@;AKH-Wien.AC.AT] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, October 23, 2002 1:01 PM To: [EMAIL PROTECTED] Subject: Failover Logic to secondary QM in JAVA I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 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
Failover Logic to secondary QM in JAVA
I am trying to code some logic that will automatically attempt to connect to a secondary server/queue manager should the first become unavailable. The question is, what error codes should this method check for that would indicate a queue manager being unavailable? So far, I think 2009 (MQRC_CONNECTION_ERROR), 2059 (MQRC_Q_MGR_NOT_AVAILABLE), 2161 (MQRC_Q_MGR_QUIESCING), 2162 (MQRC_Q_MGR_STOPPING) will cover it. Am I missing any that should be added to this method? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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
