I know that I am opening
myself up to a lot of CONSTRUCTIVE CRITICISM but I will be more than happy to
take the ‘slings and arrows’ to benefit the entire community as to what these
channel attributes should be set to. From my perspective (‘have
yet to implement this scenario in a production environment’) I would set
LongRetryCount and LongRetryInterval to ZERO and arbitrary values for
ShortRetry Count + Interval that are tailored to your production environment. Once the ShortRetry* attributes have
elapsed, the channel will go into a STOPPED state. If you give the network 10 minutes (shorretryinterval=30, shorretrycount=20)
or 60 minutes (shortretryinterval=60, shortretrycount=60) to clean itself up, isn’t
that enough? Why do I want to stay
in a retrying state FOREVER? A
more robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and
DISCINT (and optionally HBINT) attributes to break a connection within the
window defined by the ShorRetry* settings. Therefore if the channel DOES go into a STOPPED state, you
really know you have a problem. OK, I now am wearing my shield
of armor and am ready to defend myself, so let them arrows fly and see what
collective decision we can make… Steve -----Original
Message-----
This
message was content-scanned by GatewayDefender.com |
- Channel Retry Counts/Intervals Edward Pius
- Re: Channel Retry Counts/Intervals Glen Shubert
- Re: Channel Retry Counts/Intervals Stephan C. Moen
- Re: Channel Retry Counts/Intervals Heggie, Peter
- Re: Channel Retry Counts/Intervals Glen Shubert
- Re: Channel Retry Counts/Intervals Potkay, Peter M (PLC, IT)
- Re: Channel Retry Counts/Intervals Glen Larson
- Re: Channel Retry Counts/Intervals Stephan C. Moen
- Re: Channel Retry Counts/Intervals Potkay, Peter M (PLC, IT)