Hi Nuwan, Thanks a lot for your clarification. But need more explanation on your comments.
1. *if the user define only transport.jms.InitialReconnectDuration, It will always be multiplied by the transport.jms.ReconnectProgressFactor until it reach to transport.jms.MaxReconnectDuration. * We can define "transport.jms.MaxReconnectDuration" as 30 seconds and shut down the jms broker. It may increase retry time interval by ReconnectProgressFactor and doesn't consider about MaxReconnectDuration. As I know MaxReconnectDuration is used to define upper level of reconnect time limit. I don't understand exact relationship between " ReconnectProgressFactor" and "MaxReconnectDuration". Can you verify it further? When include "<parameter name ="transport.jms.MaxReconnectDuration" locked="false">30000</parameter>" and testing with exact scenario you can find logs as follows: [2016-05-18 18:01:21,257] ERROR - ServiceTaskManager Reconnection attempt : 1 for service : QueueProxy failed. Next retry in 20 seconds [2016-05-18 18:01:21,258] ERROR - ServiceTaskManager Reconnection attempt : 1 for service : TopicProxy failed. Next retry in 20 seconds [2016-05-18 18:01:51,262] ERROR - ServiceTaskManager Reconnection attempt : 2 for service : QueueProxy failed. Next retry in 40 seconds [2016-05-18 18:01:51,263] ERROR - ServiceTaskManager Reconnection attempt : 2 for service : TopicProxy failed. Next retry in 40 seconds [2016-05-18 18:02:31,269] ERROR - ServiceTaskManager Reconnection attempt : 3 for service : QueueProxy failed. Next retry in 60 seconds [2016-05-18 18:02:31,271] ERROR - ServiceTaskManager Reconnection attempt : 3 for service : TopicProxy failed. Next retry in 60 seconds 2. *if the user define only transport.jms.InitialReconnectDuration, It will always be multiplied by the transport.jms.ReconnectProgressFactor until it reach to transport.jms.MaxReconnectDuration. * I also tried above scenario while adding both InitialReconnectDuration and MaxReconnectDuration. What do you mean by "*It will always be multiplied by the transport.jms.ReconnectProgressFactor until it reach to transport.jms.MaxReconnectDuration.*" When I am testing got the same result as above scenario: <parameter name ="transport.jms.InitialReconnectDuration" locked="false">10000</parameter> <parameter name ="transport.jms.MaxReconnectDuration" locked="false">30000</parameter> Logs: [2016-05-18 18:19:02,148] ERROR - ServiceTaskManager Reconnection attempt : 1 for service : QueueProxy failed. Next retry in 20 seconds [2016-05-18 18:19:02,148] ERROR - ServiceTaskManager Reconnection attempt : 1 for service : TopicProxy failed. Next retry in 20 seconds [2016-05-18 18:19:32,153] ERROR - ServiceTaskManager Reconnection attempt : 2 for service : QueueProxy failed. Next retry in 40 seconds [2016-05-18 18:19:32,153] ERROR - ServiceTaskManager Reconnection attempt : 2 for service : TopicProxy failed. Next retry in 40 seconds Hope you will clarify more on these factors. Regards, Dilshani On Wed, May 18, 2016 at 5:53 PM, Nuwan Wimalasekara <[email protected]> wrote: > Hi Dilshani, > > If the user need to define constant interval for reconnect, user can > define transport.jms.ReconnectInterval. Then it will wait defined value for > each reconnect attempt. > > if the user define only transport.jms.InitialReconnectDuration, It will > always be multiplied by the transport.jms.ReconnectProgressFactor until > it reach to transport.jms.MaxReconnectDuration. > > transport.jms.ReconnectProgressFactor is set to 2 by default to > increasing the reconnect interval exponential until it reach > to transport.jms.MaxReconnectDuration. > > > On Wed, May 18, 2016 at 1:59 PM, Dilshani Subasinghe <[email protected]> > wrote: > >> Hi ESB Team, >> >> When consider about "JMS connection factory parameters" [1] , user can >> define "transport.jms.InitialReconnectDuration" parameter to give time >> duration which will define initial reconnection time after broken JMS >> connection. >> >> But the given value will be multiply with 2. That 2 is coming from >> "reconnectionProgressionFactor" which can be over ride by >> "transport.jms.ReconnectProgressFactor" (Which is another jms connection >> factory parameter). >> >> ServiceTaskManager.java class will handle above function as follows: >> > > >> i >> *f (reconnectDuration != null) {* >> > //if transport.jms.ReconnectInterval is available. > >> >> >> >> >> >> >> >> >> >> * retryDuration = >> reconnectDuration; log.error("Reconnection >> attempt : " + (r++) + " for service : " >> + serviceName + " failed. Next retry in >> " + (retryDuration / 1000) + " seconds. >> (Fixed Interval)"); } else >> { retryDuration = (long) (retryDuration * >> reconnectionProgressionFactor); >> log.error("Reconnection attempt : " + (r++) + " for service : " >> + serviceName + " failed. Next retry in >> " + (retryDuration / 1000) + " >> seconds");* >> >> >> There are two facts to clarify with above situation. >> >> 1. According to user perspective, it may be wrong to multiply the value >> which is given by user. >> >> Ex: User may add 10 seconds as initial retry interval, but ESB does it >> within 20 seconds. >> >> Note: When we add "transport.jms.ReconnectProgressFactor" in to >> axis2.xml, it can be override. >> >> *<parameter name ="transport.jms.ReconnectProgressFactor" >> locked="false">1</parameter>* >> >> 2. Why we hard code *reconnectionProgressionFactor *as 2 ? Can we change >> it or is it impossible because of the behavior of axis2 ? >> >> As a suggestion, it will be better to add it as 1. (It may also solve the >> problem discussed above step) >> >> >> >> >> >> */** Progression factory for geometric series that calculates >> re-connection times */ private double reconnectionProgressionFactor = >> 2.0; // default to [bounded] exponential* >> Any clarification on above factors will be really appreciated. >> >> >> [1] - https://docs.wso2.com/display/ESB500/JMS+Transport >> [2] - https://axis.apache.org/axis2/java/transports/jms.html >> >> Thank you. >> >> -- >> Best Regards, >> >> Dilshani Subasinghe >> Software Engineer - QA >> WSO2, Inc.;http://wso2.com/ >> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com%2F&sa=D&sntz=1&usg=AFQjCNGJuLRux6KkJwXKVUCYOtEsNCmIAQ> >> lean.enterprise.middleware >> Mobile: +94773375185 >> Blog: dilshanilive.blogspot.com >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Nuwan Wimalasekara > Senior Software Engineer - Test Automation > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > phone: +94 71 668 4620 > > > > -- Best Regards, Dilshani Subasinghe Software Engineer - QA WSO2, Inc.;http://wso2.com/ <http://www.google.com/url?q=http%3A%2F%2Fwso2.com%2F&sa=D&sntz=1&usg=AFQjCNGJuLRux6KkJwXKVUCYOtEsNCmIAQ> lean.enterprise.middleware Mobile: +94773375185 Blog: dilshanilive.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
