HI 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.
>

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 <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
>



-- 
Nuwan Wimalasekara
Senior Software Engineer - Test Automation
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware

phone: +94 71 668 4620
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to