Log is corrected as bellow when having below parameter values. <parameter name ="transport.jms.InitialReconnectDuration" locked="false">10000</parameter> <parameter name ="transport.jms.MaxReconnectDuration" locked="false">60000</ parameter>
[2016-05-19 11:23:20,338] ERROR - ServiceTaskManager Reconnection attempt : 1 for service : JmsProxy failed. Next retry in 20 seconds [2016-05-19 11:23:45,357] ERROR - ServiceTaskManager Reconnection attempt : 2 for service : JmsProxy failed. Next retry in 40 seconds [2016-05-19 11:24:30,378] INFO - ServiceTaskManager InitialReconnectDuration reached to MaxReconnectDuration. [2016-05-19 11:24:30,379] ERROR - ServiceTaskManager Reconnection attempt : 3 for service : JmsProxy failed. Next retry in 60 seconds [2016-05-19 11:25:35,411] INFO - ServiceTaskManager InitialReconnectDuration reached to MaxReconnectDuration. [2016-05-19 11:25:35,411] ERROR - ServiceTaskManager Reconnection attempt : 4 for service : JmsProxy failed. Next retry in 60 seconds Thanks, Nuwanw On Thu, May 19, 2016 at 11:11 AM, Dilshani Subasinghe <[email protected]> wrote: > Noted and reported a jira [1] to cover up fixing the issue. > > [1] https://wso2.org/jira/browse/ESBJAVA-4625 > > Regards, > Dilshani > > > On Thu, May 19, 2016 at 10:47 AM, Nuwan Wimalasekara <[email protected]> > wrote: > >> HI Dilshani, >> >> On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe <[email protected]> >> 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. >>> >> >> The log is not correct. It waits for MaxReconnectDuration. But logs show >> incorrect value. Thanks for reporting the issue. Will fix the logs. >> >>> >>> 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 >>> >> >> >> >> -- >> 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 > -- Nuwan Wimalasekara Senior Software Engineer - Test Automation WSO2, Inc.: http://wso2.com lean. enterprise. middleware phone: +94 71 668 4620
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
