Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Asanka Abeyweera 
+1 for first approach.

Sent from my mobile

--
Asanka Abeyweera
Software Engineer
WSO2 Inc.

Phone: +94 712228648
On Mar 21, 2015 12:57 AM, "Hasitha Hiranya"  wrote:

> +1 for the fist approach.
>
> On Fri, Mar 20, 2015 at 7:35 AM, Pamod Sylvester  wrote:
>
>> I too think option 1 is better, given the fact that the second node could
>> trigger the flow controlling upon acceptance of the first few messages if
>> its exhausted.
>>
>> On Fri, Mar 20, 2015 at 5:55 PM, Asitha Nanayakkara 
>> wrote:
>>
>>> In MB Flow controlling mechanism is cluster unaware. Hence when one node
>>> enables flow control other node doesn't know about it.
>>> IMO we have two approaches to tackle this.
>>>
>>>- After client retries to connect to killed node (after failing to
>>>connect) it will try to connect to second node. At that time, since we 
>>> are
>>>connecting to a new node, client can reset all flow control related
>>>information, from client, so that it can publish without waiting for flow
>>>control disable message from second node (That will never be sent to
>>>publisher by second node)
>>>- Or we can send a flow control disable message from MB node when a
>>>publisher connects (If global flow control is not enabled).
>>>
>>> I think the first option is better.
>>>
>>> Regards,
>>>
>>> On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage 
>>> wrote:
>>>
 Hi All,

 We did fail over testing on mb nodes in AWS instances and came across
 following issue. Following is the scenario tested in cluster.

 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
 2. Add queue subscriber "MyQueue" to nodeB.
 3. Start publish "MyQueue" queue messages to nodeA.
 4. After flow control enabled in nodeA, disconnect nodeA from the
 cluster.

 At a moment where flow control is enabled for the publisher, the
 coordinator is killed. Even though(assuming) that the publisher moves
 to the other node, it is still under flow control and the node does not
 disable the flow control for the publisher. Therefore the publisher does
 not publish any messages afterwards. How can we overcome this issue ?

 Regards,
 --
 Pumudu Ruhunage
 Associate Software Engineer | WSO2 Inc
 M: +94 779 664493  | http://wso2.com

>>>
>>>
>>>
>>> --
>>> *Asitha Nanayakkara*
>>> Software Engineer
>>> WSO2, Inc. http://wso2.com/
>>> Mob: + 94 77 85 30 682
>>>
>>>
>>
>>
>> --
>> *Pamod Sylvester *
>>  *Senior Software Engineer *
>> Integration Technologies Team, WSO2 Inc.; http://wso2.com
>> email: pa...@wso2.com cell: +94 77 7779495
>>
>
>
>
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Hasitha Hiranya 
+1 for the fist approach.

On Fri, Mar 20, 2015 at 7:35 AM, Pamod Sylvester  wrote:

> I too think option 1 is better, given the fact that the second node could
> trigger the flow controlling upon acceptance of the first few messages if
> its exhausted.
>
> On Fri, Mar 20, 2015 at 5:55 PM, Asitha Nanayakkara 
> wrote:
>
>> In MB Flow controlling mechanism is cluster unaware. Hence when one node
>> enables flow control other node doesn't know about it.
>> IMO we have two approaches to tackle this.
>>
>>- After client retries to connect to killed node (after failing to
>>connect) it will try to connect to second node. At that time, since we are
>>connecting to a new node, client can reset all flow control related
>>information, from client, so that it can publish without waiting for flow
>>control disable message from second node (That will never be sent to
>>publisher by second node)
>>- Or we can send a flow control disable message from MB node when a
>>publisher connects (If global flow control is not enabled).
>>
>> I think the first option is better.
>>
>> Regards,
>>
>> On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage  wrote:
>>
>>> Hi All,
>>>
>>> We did fail over testing on mb nodes in AWS instances and came across
>>> following issue. Following is the scenario tested in cluster.
>>>
>>> 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
>>> 2. Add queue subscriber "MyQueue" to nodeB.
>>> 3. Start publish "MyQueue" queue messages to nodeA.
>>> 4. After flow control enabled in nodeA, disconnect nodeA from the
>>> cluster.
>>>
>>> At a moment where flow control is enabled for the publisher, the
>>> coordinator is killed. Even though(assuming) that the publisher moves
>>> to the other node, it is still under flow control and the node does not
>>> disable the flow control for the publisher. Therefore the publisher does
>>> not publish any messages afterwards. How can we overcome this issue ?
>>>
>>> Regards,
>>> --
>>> Pumudu Ruhunage
>>> Associate Software Engineer | WSO2 Inc
>>> M: +94 779 664493  | http://wso2.com
>>>
>>
>>
>>
>> --
>> *Asitha Nanayakkara*
>> Software Engineer
>> WSO2, Inc. http://wso2.com/
>> Mob: + 94 77 85 30 682
>>
>>
>
>
> --
> *Pamod Sylvester *
>  *Senior Software Engineer *
> Integration Technologies Team, WSO2 Inc.; http://wso2.com
> email: pa...@wso2.com cell: +94 77 7779495
>



-- 
*Hasitha Abeykoon*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
*cell:* *+94 719363063*
*blog: **abeykoon.blogspot.com* 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Pamod Sylvester 
I too think option 1 is better, given the fact that the second node could
trigger the flow controlling upon acceptance of the first few messages if
its exhausted.

On Fri, Mar 20, 2015 at 5:55 PM, Asitha Nanayakkara  wrote:

> In MB Flow controlling mechanism is cluster unaware. Hence when one node
> enables flow control other node doesn't know about it.
> IMO we have two approaches to tackle this.
>
>- After client retries to connect to killed node (after failing to
>connect) it will try to connect to second node. At that time, since we are
>connecting to a new node, client can reset all flow control related
>information, from client, so that it can publish without waiting for flow
>control disable message from second node (That will never be sent to
>publisher by second node)
>- Or we can send a flow control disable message from MB node when a
>publisher connects (If global flow control is not enabled).
>
> I think the first option is better.
>
> Regards,
>
> On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage  wrote:
>
>> Hi All,
>>
>> We did fail over testing on mb nodes in AWS instances and came across
>> following issue. Following is the scenario tested in cluster.
>>
>> 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
>> 2. Add queue subscriber "MyQueue" to nodeB.
>> 3. Start publish "MyQueue" queue messages to nodeA.
>> 4. After flow control enabled in nodeA, disconnect nodeA from the cluster.
>>
>> At a moment where flow control is enabled for the publisher, the
>> coordinator is killed. Even though(assuming) that the publisher moves to
>> the other node, it is still under flow control and the node does not
>> disable the flow control for the publisher. Therefore the publisher does
>> not publish any messages afterwards. How can we overcome this issue ?
>>
>> Regards,
>> --
>> Pumudu Ruhunage
>> Associate Software Engineer | WSO2 Inc
>> M: +94 779 664493  | http://wso2.com
>>
>
>
>
> --
> *Asitha Nanayakkara*
> Software Engineer
> WSO2, Inc. http://wso2.com/
> Mob: + 94 77 85 30 682
>
>


-- 
*Pamod Sylvester *
 *Senior Software Engineer *
Integration Technologies Team, WSO2 Inc.; http://wso2.com
email: pa...@wso2.com cell: +94 77 7779495
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Ramith Jayasinghe 
first one seems the correct way to me. thoughts?

On Fri, Mar 20, 2015 at 5:55 PM, Asitha Nanayakkara  wrote:

> In MB Flow controlling mechanism is cluster unaware. Hence when one node
> enables flow control other node doesn't know about it.
> IMO we have two approaches to tackle this.
>
>- After client retries to connect to killed node (after failing to
>connect) it will try to connect to second node. At that time, since we are
>connecting to a new node, client can reset all flow control related
>information, from client, so that it can publish without waiting for flow
>control disable message from second node (That will never be sent to
>publisher by second node)
>- Or we can send a flow control disable message from MB node when a
>publisher connects (If global flow control is not enabled).
>
> I think the first option is better.
>
> Regards,
>
> On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage  wrote:
>
>> Hi All,
>>
>> We did fail over testing on mb nodes in AWS instances and came across
>> following issue. Following is the scenario tested in cluster.
>>
>> 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
>> 2. Add queue subscriber "MyQueue" to nodeB.
>> 3. Start publish "MyQueue" queue messages to nodeA.
>> 4. After flow control enabled in nodeA, disconnect nodeA from the cluster.
>>
>> At a moment where flow control is enabled for the publisher, the
>> coordinator is killed. Even though(assuming) that the publisher moves to
>> the other node, it is still under flow control and the node does not
>> disable the flow control for the publisher. Therefore the publisher does
>> not publish any messages afterwards. How can we overcome this issue ?
>>
>> Regards,
>> --
>> Pumudu Ruhunage
>> Associate Software Engineer | WSO2 Inc
>> M: +94 779 664493  | http://wso2.com
>>
>
>
>
> --
> *Asitha Nanayakkara*
> Software Engineer
> WSO2, Inc. http://wso2.com/
> Mob: + 94 77 85 30 682
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Asitha Nanayakkara 
In MB Flow controlling mechanism is cluster unaware. Hence when one node
enables flow control other node doesn't know about it.
IMO we have two approaches to tackle this.

   - After client retries to connect to killed node (after failing to
   connect) it will try to connect to second node. At that time, since we are
   connecting to a new node, client can reset all flow control related
   information, from client, so that it can publish without waiting for flow
   control disable message from second node (That will never be sent to
   publisher by second node)
   - Or we can send a flow control disable message from MB node when a
   publisher connects (If global flow control is not enabled).

I think the first option is better.

Regards,

On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage  wrote:

> Hi All,
>
> We did fail over testing on mb nodes in AWS instances and came across
> following issue. Following is the scenario tested in cluster.
>
> 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
> 2. Add queue subscriber "MyQueue" to nodeB.
> 3. Start publish "MyQueue" queue messages to nodeA.
> 4. After flow control enabled in nodeA, disconnect nodeA from the cluster.
>
> At a moment where flow control is enabled for the publisher, the
> coordinator is killed. Even though(assuming) that the publisher moves to
> the other node, it is still under flow control and the node does not
> disable the flow control for the publisher. Therefore the publisher does
> not publish any messages afterwards. How can we overcome this issue ?
>
> Regards,
> --
> Pumudu Ruhunage
> Associate Software Engineer | WSO2 Inc
> M: +94 779 664493  | http://wso2.com
>



-- 
*Asitha Nanayakkara*
Software Engineer
WSO2, Inc. http://wso2.com/
Mob: + 94 77 85 30 682
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Hemika Kodikara 
We would have to keep the flow control status per publisher across the
cluster I suppose. Is there a way through client to retry publishing after
sometime ? Which can be set through the AMQP url ?

Regards,
Hemika

Hemika Kodikara
Software Engineer
WSO2 Inc.
lean . enterprise . middleware
http://wso2.com

Mobile : +9477762

On Fri, Mar 20, 2015 at 3:32 PM, Pumudu Ruhunage  wrote:

> Hi All,
>
> We did fail over testing on mb nodes in AWS instances and came across
> following issue. Following is the scenario tested in cluster.
>
> 1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
> 2. Add queue subscriber "MyQueue" to nodeB.
> 3. Start publish "MyQueue" queue messages to nodeA.
> 4. After flow control enabled in nodeA, disconnect nodeA from the cluster.
>
> At a moment where flow control is enabled for the publisher, the
> coordinator is killed. Even though(assuming) that the publisher moves to
> the other node, it is still under flow control and the node does not
> disable the flow control for the publisher. Therefore the publisher does
> not publish any messages afterwards. How can we overcome this issue ?
>
> Regards,
> --
> Pumudu Ruhunage
> Associate Software Engineer | WSO2 Inc
> M: +94 779 664493  | http://wso2.com
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [MB] How to handle flow controling in a event of fail-over

2015-03-20 Thread Pumudu Ruhunage 
Hi All,

We did fail over testing on mb nodes in AWS instances and came across
following issue. Following is the scenario tested in cluster.

1. Start 2 node mb cluster with nodeA (coordinator), nodeB.
2. Add queue subscriber "MyQueue" to nodeB.
3. Start publish "MyQueue" queue messages to nodeA.
4. After flow control enabled in nodeA, disconnect nodeA from the cluster.

At a moment where flow control is enabled for the publisher, the
coordinator is killed. Even though(assuming) that the publisher moves to
the other node, it is still under flow control and the node does not
disable the flow control for the publisher. Therefore the publisher does
not publish any messages afterwards. How can we overcome this issue ?

Regards,
-- 
Pumudu Ruhunage
Associate Software Engineer | WSO2 Inc
M: +94 779 664493  | http://wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev