In previous mail, I am referring both points to same thing. Please consider, it should be correct as follows:
1. *transport.jms.ReconnectProgressFactor is set to 2 by default to increasing the reconnect interval exponential until it reach to transport.jms.MaxReconnectDuration. * 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. * Regards, Dilshani On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe <dilsh...@wso2.com> wrote: > 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 <nuw...@wso2.com> > 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 <dilsh...@wso2.com> >> 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 >>> Dev@wso2.org >>> 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 > -- 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev