subject:"\[Dev\] \[ESB\]\[JMS\] \"transport.jms.InitialReconnectDuration\" parameter will automatically multiply with \"transport.jms.ReconnectProgressFactor\""

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-19 Thread Dilshani Subasinghe

Noted and appreciate quick response.

Regards,
Dilshani

On Thu, May 19, 2016 at 11:31 AM, Nuwan Wimalasekara 
wrote:

> Log is corrected as bellow when having below parameter values.
>
>  locked="false">1
>  locked="false">6
>
> [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 
> 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 
>> wrote:
>>
>>> HI Dilshani,
>>>
>>> On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe 
>>> 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 ">>> locked="false">3" 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:

 >>> locked="false">1
 >>> locked="false">3

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

> Hi Dilshani,
>
> If the user need to define constant interval for reconnect, user can

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-19 Thread Nuwan Wimalasekara

Log is corrected as bellow when having below parameter values.

1
6

[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 
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 
> wrote:
>
>> HI Dilshani,
>>
>> On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe 
>> 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 ">> locked="false">3" 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:
>>>
>>> >> locked="false">1
>>> >> locked="false">3
>>>
>>> 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 
>>> 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.

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Dilshani Subasinghe

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

> HI Dilshani,
>
> On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe 
> 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 "> locked="false">3" 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:
>>
>> > locked="false">1
>> > locked="false">3
>>
>> 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 
>> 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 
>>> 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.
>>>

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Nuwan Wimalasekara

HI Dilshani,

On Wed, May 18, 2016 at 6:27 PM, Dilshani Subasinghe 
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 " locked="false">3" 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:
>
>  locked="false">1
>  locked="false">3
>
> 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 
> 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 
>> 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) +"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Dilshani Subasinghe

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 
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 " locked="false">3" 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:
>
>  locked="false">1
>  locked="false">3
>
> 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 
> 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 
>> 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.
>>
>>>
>>>
>>>

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Dilshani Subasinghe

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 "3" 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:

1
3

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

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Nuwan Wimalasekara

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 
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.
>
> * locked="false">1*
>
> 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/
> 
> 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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

2016-05-18 Thread Dilshani Subasinghe

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) {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.

*1*

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/

lean.enterprise.middleware
Mobile: +94773375185
Blog: dilshanilive.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

Re: [Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

[Dev] [ESB][JMS] "transport.jms.InitialReconnectDuration" parameter will automatically multiply with "transport.jms.ReconnectProgressFactor"

8 matches

Site Navigation

Mail list logo

Footer information