Long and Short Retry Dilemma/Question???
What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: Short Retry Interval: 60 seconds Short Retry Count: 10 Long Retry Interval: 1200 seconds Long Retry Count: 9 Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings. Here are some thoughts: If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes. Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue. Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in. Just wondering what some of your thoughts were on this issue. Thanks. Mike Davidson TSYS WebSphere MQ Technical Support [EMAIL PROTECTED]
Re: Long and Short Retry Dilemma/Question???
We use 60,60,60, Try every minute for 1 hour, and then try every minute for a really long time. Any more frequent than that and we were worried about filling our error logs. Any less than that and we felt we would be waiting to long to recover. -Original Message-From: Mike Davidson [mailto:[EMAIL PROTECTED]Sent: Thursday, May 29, 2003 11:07 AMTo: [EMAIL PROTECTED]Subject: Long and Short Retry Dilemma/Question???What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: Short Retry Interval: 60 seconds Short Retry Count: 10 Long Retry Interval: 1200 seconds Long Retry Count: 9 Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings. Here are some thoughts: If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes. Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue. Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in. Just wondering what some of your thoughts were on this issue. Thanks. Mike DavidsonTSYS WebSphere MQ Technical Support[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: Long and Short Retry Dilemma/Question???
Mike, We struggled w/ this same problem several years ago and finally settled on the following: Short Retry Interval: 60 seconds Short Retry Count: 10 Long Retry Interval: 180 seconds Long Retry Count: 9 Disconnect Interval: 600 seconds Our thoughts were that a 'temporary problem' would have 10 minutes to clear-up (10 x 1 minute), with 'more severe' problems having an unlimited number of 3-minute cycles to be corrected. I agree that the 20 minute default is much too high, which is why we went to a 3-minute interval. In addition, even though you did not ask about the Disconnect Interval, I included it for 'completeness'. We went to a 10-minute cycle of inactivity for several reasons. First, it makes it much easier to shut down a subsystem when your channels are inactive. Prior to scheduled IPLs, we shut down all our applications first, allowing any msgs 'in the pipeline' to reach their destinations. Then we can stop the subsystem w/o having to worry about stopping/terminating channels. The second reason might be more application specific, but we found that if we did not receive any msgs within 10 minutes, it was usually the case that it would be awhile before the next batch of msgs would arrive. Before settling on 10 minutes, we had tried a 5 minute interval, only to find out that our CHIN was doing a lot of STOP/START 'thrashing'. Hope this info helps you in selecting what is best for your shop. Regards, Art Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified Specialist / Solutions Expert - MQSeries (804) 697-3889 [EMAIL PROTECTED] Mike Davidson <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 05/29/2003 11:07 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Long and Short Retry Dilemma/Question??? What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: Short Retry Interval: 60 seconds Short Retry Count: 10 Long Retry Interval: 1200 seconds Long Retry Count: 9 Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings. Here are some thoughts: If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes. Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue. Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in. Just wondering what some of your thoughts were on this issue. Thanks. Mike Davidson TSYS WebSphere MQ Technical Support [EMAIL PROTECTED]
Re: Long and Short Retry Dilemma/Question???
We use 30,120,300,9. Try every 30 seconds for 1 hour, then every 5 minutes forever. We get a lot of sporadic network errors that recover quickly, and this seems to work well for them. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM> Subject: Re: Long and Short Retry Dilemma/Question??? Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 05/29/2003 10:14 AM Please respond to MQSeries List We use 60,60,60, Try every minute for 1 hour, and then try every minute for a really long time. Any more frequent than that and we were worried about filling our error logs. Any less than that and we felt we would be waiting to long to recover. -Original Message- From: Mike Davidson [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 11:07 AM To: [EMAIL PROTECTED] Subject: Long and Short Retry Dilemma/Question??? What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: Short Retry Interval: 60 seconds Short Retry Count:10 Long Retry Interval:1200 seconds Long Retry Count:9 Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings. Here are some thoughts: If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes. Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue. Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in. Just wondering what some of your thoughts were on this issue. Thanks. Mike Davidson TSYS WebSphere MQ Technical Support [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. 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: Long and Short Retry Dilemma/Question???
whoops I meant 60,60,600,9 Try every TEN minutes forever after short retry. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 11:41 AM To: [EMAIL PROTECTED] Subject: Re: Long and Short Retry Dilemma/Question??? We use 30,120,300,9. Try every 30 seconds for 1 hour, then every 5 minutes forever. We get a lot of sporadic network errors that recover quickly, and this seems to work well for them. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM> Subject: Re: Long and Short Retry Dilemma/Question??? Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 05/29/2003 10:14 AM Please respond to MQSeries List We use 60,60,60, Try every minute for 1 hour, and then try every minute for a really long time. Any more frequent than that and we were worried about filling our error logs. Any less than that and we felt we would be waiting to long to recover. -Original Message- From: Mike Davidson [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 11:07 AM To: [EMAIL PROTECTED] Subject: Long and Short Retry Dilemma/Question??? What is the general consensus for settings of the Long and Short Retry Interval/Count attributes. I apologize if this has been discussed before, and I'm sure it has been. We are currently running 5.3 on z/OS. The defaults for these attributes are as follows: Short Retry Interval: 60 seconds Short Retry Count:10 Long Retry Interval:1200 seconds Long Retry Count:9 Historically, we've taken the defaults - but lately we've had some issues come up that have prompted us to revisit these attribute settings. Here are some thoughts: If a sender channel goes into retry (let's say b/c of network problems) and it's still not resolved after 10 minutes and the channel is into its Long Retry and a client (business client, not an MQ Client) has to wait for 20 minutes for the next retry - that seems kind of long to wait. We were considering maybe changing it to 10 minutes. Obviously this adds some overhead - but it kind of seems worth the sacrifice. I know that if I'm on the other end of a channel and I resolve the network issue, I'm not going to want to wait 20 minutes for the sender to retry - especially if this is a production issue. Also, would it be worth it to increase the Short Retry interval to 2 minutes for a Count of 20? Thus, giving more time for the issue to be resolved before the Long Retry kicks in. Just wondering what some of your thoughts were on this issue. Thanks. Mike Davidson TSYS WebSphere MQ Technical Support [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. 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
