Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Srinath Perera]

Hi Sajini,

Great!! make sure it works on all scenarios. e.g. from UI and also when
user list subscriptions via API and want to delete them etc.

Thanks
Srinath

On Thu, Dec 3, 2015 at 4:16 PM, Sajini De Silva  wrote:

> Hi Srinath,
>
> For durable subscriptions, IP address of the node is appended to
> subscription ID. Currently for queue subscriptions, we don't do that. We
> can append it to subscription ID for queue subscriptions as well as in
> durable subscriptions.
>
> Thank you
> Sajini
>
> On Thu, Dec 3, 2015 at 3:31 PM, Srinath Perera  wrote:
>
>> If the user must go to the node where subscription is made to disconnect
>> the subscription, we might need to give a way for a user to find which node
>> has what subscriptions.
>>
>> --Srinath
>>
>> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
>> wrote:
>>
>>> I propose,
>>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>>> approach).
>>>  2) there need to be a permission around it.
>>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>>> whose misbehaving.
>>>
>>>
>>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva 
>>> wrote:
>>>
 Hi Hasitha,

 We haven't implemented the MQTT UI yet. Therefore IMO its better not to
 implement this feature for MQTT for now. We can consider it when
 implementing MQTT UI in our major release. WDYT?

 Thank you,
 Sajini

 On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
 wrote:

> Hi,
>
> There is a feature request that Message Broker should support to
> forcefully disconnect a subscriber. This means, server should be able to
> disconnect misbehaving subscribers. Server has a control over it.
>
> Steps to do this would be
>
> 1. Find a way to disconnect the socket from mina transport level.
> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>
> At step two the node that is disconnecting  the socket, will broadcast
> a Hazelcast message that this subscriber is closed.
>
> With above implementation steps, a limitation is introduced as "you
> can only disconnect the subscribers originated to that node only". For
> example, say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 
> and
> sub2 for MB2. You need to go to MB1's web console to disconnect sub1 and
> MB2's web console to disconnect sub2. So cluster aspect is lost there.
>
> Thus two implementation approaches are there
>
> 1. Forceful disconnection can be done only from the node subscriber is
> connected to.
> 2. Forceful disconnection can be done from any node (this is bit
> complex. Involves Hazelcast notifications)
>
> As our end goal for implementation would option 1 be adequate?
> Or do we need to reach out for option 2 as well?
> Do we need to facilitate this for any subscription type
> (queue/topic/durable topic/shared durable topic) ? What about MQTT
> subscribers?
>
> Also what are the permissions a user should have to perform this
> action? Are we going to introduce a new permission type?
>
> Thanks
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Sajini De SIlva
 Software Engineer; WSO2 Inc.; http://wso2.com ,
 Email: saj...@wso2.com
 Blog: http://sajinid.blogspot.com/
 Git hub profile: https://github.com/sajinidesilva

 Phone: +94 712797729


>>>
>>>
>>> --
>>> Ramith Jayasinghe
>>> Technical Lead
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> E: ram...@wso2.com
>>> P: +94 777542851
>>>
>>>
>>
>>
>> --
>> 
>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>> Site: http://people.apache.org/~hemapani/
>> Photos: http://www.flickr.com/photos/hemapani/
>> Phone: 0772360902
>>
>
>
>
> --
> Sajini De SIlva
> Software Engineer; WSO2 Inc.; http://wso2.com ,
> Email: saj...@wso2.com
> Blog: http://sajinid.blogspot.com/
> Git hub profile: https://github.com/sajinidesilva
>
> Phone: +94 712797729
>
>


-- 

Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
Site: http://people.apache.org/~hemapani/
Photos: http://www.flickr.com/photos/hemapani/
Phone: 0772360902
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Hasitha Hiranya]

Hi,

As agreed, we implemented the feature. You can only close "local
subscriptions" from management console. You cannot close subscriptions on
any other node.

Management console is displayed as below.

[image: Inline image 1]

Thanks

On Fri, Dec 4, 2015 at 2:57 PM, Hasitha Hiranya  wrote:

> Hi,
>
> While implementing the feature we have this permission problem w:r:t
> permission tree. We want to restrict following two operations
>
> >> subscription browse
> >> subscription close (this new feature)
>
> Following are possible permission scenarios
>
> 1. One should be able to browse without close permission
> 2. To be able to close subscription, user must have browse permission
> (close button is in browse page)
>
> Currently we cannot cater for this requirement. We cannot de-select
> "Close" when "Queue" is selected (browse permission given by "Queue")
>
> Please consider following image
>
> [image: Inline image 1]
>
> Is there any better way to do this other than using same level permissions
> for subscription browse and subscriptions close (no dependency can be
> enforced)?
>
> Thanks
>
> On Thu, Dec 3, 2015 at 7:10 PM, Frank Leymann  wrote:
>
>> +1
>> I would even say stronger "...we MUST give a way..."
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-12-03 11:01 GMT+01:00 Srinath Perera :
>>
>>> If the user must go to the node where subscription is made to disconnect
>>> the subscription, we might need to give a way for a user to find which node
>>> has what subscriptions.
>>>
>>> --Srinath
>>>
>>> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
>>> wrote:
>>>
 I propose,
  1) user cant disconnect consumers in another nodes. ( simplifies the
 approach).
  2) there need to be a permission around it.
  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
 whose misbehaving.


 On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva 
 wrote:

> Hi Hasitha,
>
> We haven't implemented the MQTT UI yet. Therefore IMO its better not
> to implement this feature for MQTT for now. We can consider it when
> implementing MQTT UI in our major release. WDYT?
>
> Thank you,
> Sajini
>
> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
> wrote:
>
>> Hi,
>>
>> There is a feature request that Message Broker should support to
>> forcefully disconnect a subscriber. This means, server should be able to
>> disconnect misbehaving subscribers. Server has a control over it.
>>
>> Steps to do this would be
>>
>> 1. Find a way to disconnect the socket from mina transport level.
>> 2. Send a message to Andes core to delete (disconnect) the
>> subscriber.
>>
>> At step two the node that is disconnecting  the socket, will
>> broadcast a Hazelcast message that this subscriber is closed.
>>
>> With above implementation steps, a limitation is introduced as "you
>> can only disconnect the subscribers originated to that node only". For
>> example, say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 
>> and
>> sub2 for MB2. You need to go to MB1's web console to disconnect sub1 and
>> MB2's web console to disconnect sub2. So cluster aspect is lost there.
>>
>> Thus two implementation approaches are there
>>
>> 1. Forceful disconnection can be done only from the node subscriber
>> is connected to.
>> 2. Forceful disconnection can be done from any node (this is bit
>> complex. Involves Hazelcast notifications)
>>
>> As our end goal for implementation would option 1 be adequate?
>> Or do we need to reach out for option 2 as well?
>> Do we need to facilitate this for any subscription type
>> (queue/topic/durable topic/shared durable topic) ? What about MQTT
>> subscribers?
>>
>> Also what are the permissions a user should have to perform this
>> action? Are we going to introduce a new permission type?
>>
>> Thanks
>> --
>> *Hasitha Abeykoon*
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>> *cell:* *+94 719363063*
>> *blog: **abeykoon.blogspot.com* 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajini De SIlva
> Software Engineer; WSO2 Inc.; http://wso2.com ,
> Email: saj...@wso2.com
> Blog: http://sajinid.blogspot.com/
> Git hub profile: https://github.com/sajinidesilva
>
> Phone: +94 712797729
>
>


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

 E: ram...@wso2.com
 P: +94 777542851


>>>
>>>
>>> --
>>> 
>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Hasitha Hiranya]

Hi,

While implementing the feature we have this permission problem w:r:t
permission tree. We want to restrict following two operations

>> subscription browse
>> subscription close (this new feature)

Following are possible permission scenarios

1. One should be able to browse without close permission
2. To be able to close subscription, user must have browse permission
(close button is in browse page)

Currently we cannot cater for this requirement. We cannot de-select "Close"
when "Queue" is selected (browse permission given by "Queue")

Please consider following image

[image: Inline image 1]

Is there any better way to do this other than using same level permissions
for subscription browse and subscriptions close (no dependency can be
enforced)?

Thanks

On Thu, Dec 3, 2015 at 7:10 PM, Frank Leymann  wrote:

> +1
> I would even say stronger "...we MUST give a way..."
>
>
> Best regards,
> Frank
>
> 2015-12-03 11:01 GMT+01:00 Srinath Perera :
>
>> If the user must go to the node where subscription is made to disconnect
>> the subscription, we might need to give a way for a user to find which node
>> has what subscriptions.
>>
>> --Srinath
>>
>> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
>> wrote:
>>
>>> I propose,
>>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>>> approach).
>>>  2) there need to be a permission around it.
>>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>>> whose misbehaving.
>>>
>>>
>>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva 
>>> wrote:
>>>
 Hi Hasitha,

 We haven't implemented the MQTT UI yet. Therefore IMO its better not to
 implement this feature for MQTT for now. We can consider it when
 implementing MQTT UI in our major release. WDYT?

 Thank you,
 Sajini

 On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
 wrote:

> Hi,
>
> There is a feature request that Message Broker should support to
> forcefully disconnect a subscriber. This means, server should be able to
> disconnect misbehaving subscribers. Server has a control over it.
>
> Steps to do this would be
>
> 1. Find a way to disconnect the socket from mina transport level.
> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>
> At step two the node that is disconnecting  the socket, will broadcast
> a Hazelcast message that this subscriber is closed.
>
> With above implementation steps, a limitation is introduced as "you
> can only disconnect the subscribers originated to that node only". For
> example, say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 
> and
> sub2 for MB2. You need to go to MB1's web console to disconnect sub1 and
> MB2's web console to disconnect sub2. So cluster aspect is lost there.
>
> Thus two implementation approaches are there
>
> 1. Forceful disconnection can be done only from the node subscriber is
> connected to.
> 2. Forceful disconnection can be done from any node (this is bit
> complex. Involves Hazelcast notifications)
>
> As our end goal for implementation would option 1 be adequate?
> Or do we need to reach out for option 2 as well?
> Do we need to facilitate this for any subscription type
> (queue/topic/durable topic/shared durable topic) ? What about MQTT
> subscribers?
>
> Also what are the permissions a user should have to perform this
> action? Are we going to introduce a new permission type?
>
> Thanks
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Sajini De SIlva
 Software Engineer; WSO2 Inc.; http://wso2.com ,
 Email: saj...@wso2.com
 Blog: http://sajinid.blogspot.com/
 Git hub profile: https://github.com/sajinidesilva

 Phone: +94 712797729


>>>
>>>
>>> --
>>> Ramith Jayasinghe
>>> Technical Lead
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> E: ram...@wso2.com
>>> P: +94 777542851
>>>
>>>
>>
>>
>> --
>> 
>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>> Site: http://people.apache.org/~hemapani/
>> Photos: http://www.flickr.com/photos/hemapani/
>> Phone: 0772360902
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*H

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Frank Leymann]

+1
I would even say stronger "...we MUST give a way..."


Best regards,
Frank

2015-12-03 11:01 GMT+01:00 Srinath Perera :

> If the user must go to the node where subscription is made to disconnect
> the subscription, we might need to give a way for a user to find which node
> has what subscriptions.
>
> --Srinath
>
> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
> wrote:
>
>> I propose,
>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>> approach).
>>  2) there need to be a permission around it.
>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>> whose misbehaving.
>>
>>
>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:
>>
>>> Hi Hasitha,
>>>
>>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
>>> implement this feature for MQTT for now. We can consider it when
>>> implementing MQTT UI in our major release. WDYT?
>>>
>>> Thank you,
>>> Sajini
>>>
>>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
>>> wrote:
>>>
 Hi,

 There is a feature request that Message Broker should support to
 forcefully disconnect a subscriber. This means, server should be able to
 disconnect misbehaving subscribers. Server has a control over it.

 Steps to do this would be

 1. Find a way to disconnect the socket from mina transport level.
 2. Send a message to Andes core to delete (disconnect) the subscriber.

 At step two the node that is disconnecting  the socket, will broadcast
 a Hazelcast message that this subscriber is closed.

 With above implementation steps, a limitation is introduced as "you can
 only disconnect the subscribers originated to that node only". For example,
 say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
 MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
 console to disconnect sub2. So cluster aspect is lost there.

 Thus two implementation approaches are there

 1. Forceful disconnection can be done only from the node subscriber is
 connected to.
 2. Forceful disconnection can be done from any node (this is bit
 complex. Involves Hazelcast notifications)

 As our end goal for implementation would option 1 be adequate?
 Or do we need to reach out for option 2 as well?
 Do we need to facilitate this for any subscription type
 (queue/topic/durable topic/shared durable topic) ? What about MQTT
 subscribers?

 Also what are the permissions a user should have to perform this
 action? Are we going to introduce a new permission type?

 Thanks
 --
 *Hasitha Abeykoon*
 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 *cell:* *+94 719363063*
 *blog: **abeykoon.blogspot.com* 


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Sajini De SIlva
>>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>>> Email: saj...@wso2.com
>>> Blog: http://sajinid.blogspot.com/
>>> Git hub profile: https://github.com/sajinidesilva
>>>
>>> Phone: +94 712797729
>>>
>>>
>>
>>
>> --
>> Ramith Jayasinghe
>> Technical Lead
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> E: ram...@wso2.com
>> P: +94 777542851
>>
>>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Asanka Abeyweera]

Hi Sajini,

We don't have to append the Node ID. We already keep the subscribed node ID
with the subscription object [1]. We can display that information in the UI.

[1].
https://github.com/wso2/andes/blob/master/modules/andes-core/broker/src/main/java/org/wso2/andes/kernel/AndesSubscription.java#L57

On Thu, Dec 3, 2015 at 4:16 PM, Sajini De Silva  wrote:

> Hi Srinath,
>
> For durable subscriptions, IP address of the node is appended to
> subscription ID. Currently for queue subscriptions, we don't do that. We
> can append it to subscription ID for queue subscriptions as well as in
> durable subscriptions.
>
> Thank you
> Sajini
>
> On Thu, Dec 3, 2015 at 3:31 PM, Srinath Perera  wrote:
>
>> If the user must go to the node where subscription is made to disconnect
>> the subscription, we might need to give a way for a user to find which node
>> has what subscriptions.
>>
>> --Srinath
>>
>> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
>> wrote:
>>
>>> I propose,
>>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>>> approach).
>>>  2) there need to be a permission around it.
>>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>>> whose misbehaving.
>>>
>>>
>>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva 
>>> wrote:
>>>
 Hi Hasitha,

 We haven't implemented the MQTT UI yet. Therefore IMO its better not to
 implement this feature for MQTT for now. We can consider it when
 implementing MQTT UI in our major release. WDYT?

 Thank you,
 Sajini

 On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
 wrote:

> Hi,
>
> There is a feature request that Message Broker should support to
> forcefully disconnect a subscriber. This means, server should be able to
> disconnect misbehaving subscribers. Server has a control over it.
>
> Steps to do this would be
>
> 1. Find a way to disconnect the socket from mina transport level.
> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>
> At step two the node that is disconnecting  the socket, will broadcast
> a Hazelcast message that this subscriber is closed.
>
> With above implementation steps, a limitation is introduced as "you
> can only disconnect the subscribers originated to that node only". For
> example, say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 
> and
> sub2 for MB2. You need to go to MB1's web console to disconnect sub1 and
> MB2's web console to disconnect sub2. So cluster aspect is lost there.
>
> Thus two implementation approaches are there
>
> 1. Forceful disconnection can be done only from the node subscriber is
> connected to.
> 2. Forceful disconnection can be done from any node (this is bit
> complex. Involves Hazelcast notifications)
>
> As our end goal for implementation would option 1 be adequate?
> Or do we need to reach out for option 2 as well?
> Do we need to facilitate this for any subscription type
> (queue/topic/durable topic/shared durable topic) ? What about MQTT
> subscribers?
>
> Also what are the permissions a user should have to perform this
> action? Are we going to introduce a new permission type?
>
> Thanks
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Sajini De SIlva
 Software Engineer; WSO2 Inc.; http://wso2.com ,
 Email: saj...@wso2.com
 Blog: http://sajinid.blogspot.com/
 Git hub profile: https://github.com/sajinidesilva

 Phone: +94 712797729


>>>
>>>
>>> --
>>> Ramith Jayasinghe
>>> Technical Lead
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> E: ram...@wso2.com
>>> P: +94 777542851
>>>
>>>
>>
>>
>> --
>> 
>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>> Site: http://people.apache.org/~hemapani/
>> Photos: http://www.flickr.com/photos/hemapani/
>> Phone: 0772360902
>>
>
>
>
> --
> Sajini De SIlva
> Software Engineer; WSO2 Inc.; http://wso2.com ,
> Email: saj...@wso2.com
> Blog: http://sajinid.blogspot.com/
> Git hub profile: https://github.com/sajinidesilva
>
> Phone: +94 712797729
>
>


-- 
Asanka Abeyweera
Software Engineer
WSO2 Inc.

Phone: +94 712228648
Blog: a5anka.github.io
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Sajini De Silva]

Hi Srinath,

For durable subscriptions, IP address of the node is appended to
subscription ID. Currently for queue subscriptions, we don't do that. We
can append it to subscription ID for queue subscriptions as well as in
durable subscriptions.

Thank you
Sajini

On Thu, Dec 3, 2015 at 3:31 PM, Srinath Perera  wrote:

> If the user must go to the node where subscription is made to disconnect
> the subscription, we might need to give a way for a user to find which node
> has what subscriptions.
>
> --Srinath
>
> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
> wrote:
>
>> I propose,
>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>> approach).
>>  2) there need to be a permission around it.
>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>> whose misbehaving.
>>
>>
>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:
>>
>>> Hi Hasitha,
>>>
>>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
>>> implement this feature for MQTT for now. We can consider it when
>>> implementing MQTT UI in our major release. WDYT?
>>>
>>> Thank you,
>>> Sajini
>>>
>>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
>>> wrote:
>>>
 Hi,

 There is a feature request that Message Broker should support to
 forcefully disconnect a subscriber. This means, server should be able to
 disconnect misbehaving subscribers. Server has a control over it.

 Steps to do this would be

 1. Find a way to disconnect the socket from mina transport level.
 2. Send a message to Andes core to delete (disconnect) the subscriber.

 At step two the node that is disconnecting  the socket, will broadcast
 a Hazelcast message that this subscriber is closed.

 With above implementation steps, a limitation is introduced as "you can
 only disconnect the subscribers originated to that node only". For example,
 say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
 MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
 console to disconnect sub2. So cluster aspect is lost there.

 Thus two implementation approaches are there

 1. Forceful disconnection can be done only from the node subscriber is
 connected to.
 2. Forceful disconnection can be done from any node (this is bit
 complex. Involves Hazelcast notifications)

 As our end goal for implementation would option 1 be adequate?
 Or do we need to reach out for option 2 as well?
 Do we need to facilitate this for any subscription type
 (queue/topic/durable topic/shared durable topic) ? What about MQTT
 subscribers?

 Also what are the permissions a user should have to perform this
 action? Are we going to introduce a new permission type?

 Thanks
 --
 *Hasitha Abeykoon*
 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 *cell:* *+94 719363063*
 *blog: **abeykoon.blogspot.com* 


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Sajini De SIlva
>>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>>> Email: saj...@wso2.com
>>> Blog: http://sajinid.blogspot.com/
>>> Git hub profile: https://github.com/sajinidesilva
>>>
>>> Phone: +94 712797729
>>>
>>>
>>
>>
>> --
>> Ramith Jayasinghe
>> Technical Lead
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> E: ram...@wso2.com
>> P: +94 777542851
>>
>>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>



-- 
Sajini De SIlva
Software Engineer; WSO2 Inc.; http://wso2.com ,
Email: saj...@wso2.com
Blog: http://sajinid.blogspot.com/
Git hub profile: https://github.com/sajinidesilva

Phone: +94 712797729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Srinath Perera]

If the user must go to the node where subscription is made to disconnect
the subscription, we might need to give a way for a user to find which node
has what subscriptions.

--Srinath

On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe  wrote:

> I propose,
>  1) user cant disconnect consumers in another nodes. ( simplifies the
> approach).
>  2) there need to be a permission around it.
>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
> whose misbehaving.
>
>
> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:
>
>> Hi Hasitha,
>>
>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
>> implement this feature for MQTT for now. We can consider it when
>> implementing MQTT UI in our major release. WDYT?
>>
>> Thank you,
>> Sajini
>>
>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
>> wrote:
>>
>>> Hi,
>>>
>>> There is a feature request that Message Broker should support to
>>> forcefully disconnect a subscriber. This means, server should be able to
>>> disconnect misbehaving subscribers. Server has a control over it.
>>>
>>> Steps to do this would be
>>>
>>> 1. Find a way to disconnect the socket from mina transport level.
>>> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>>>
>>> At step two the node that is disconnecting  the socket, will broadcast a
>>> Hazelcast message that this subscriber is closed.
>>>
>>> With above implementation steps, a limitation is introduced as "you can
>>> only disconnect the subscribers originated to that node only". For example,
>>> say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
>>> MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
>>> console to disconnect sub2. So cluster aspect is lost there.
>>>
>>> Thus two implementation approaches are there
>>>
>>> 1. Forceful disconnection can be done only from the node subscriber is
>>> connected to.
>>> 2. Forceful disconnection can be done from any node (this is bit
>>> complex. Involves Hazelcast notifications)
>>>
>>> As our end goal for implementation would option 1 be adequate?
>>> Or do we need to reach out for option 2 as well?
>>> Do we need to facilitate this for any subscription type
>>> (queue/topic/durable topic/shared durable topic) ? What about MQTT
>>> subscribers?
>>>
>>> Also what are the permissions a user should have to perform this action?
>>> Are we going to introduce a new permission type?
>>>
>>> Thanks
>>> --
>>> *Hasitha Abeykoon*
>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>>> *cell:* *+94 719363063*
>>> *blog: **abeykoon.blogspot.com* 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sajini De SIlva
>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>> Email: saj...@wso2.com
>> Blog: http://sajinid.blogspot.com/
>> Git hub profile: https://github.com/sajinidesilva
>>
>> Phone: +94 712797729
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> E: ram...@wso2.com
> P: +94 777542851
>
>


-- 

Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
Site: http://people.apache.org/~hemapani/
Photos: http://www.flickr.com/photos/hemapani/
Phone: 0772360902
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Pamod Sylvester]

Another point i could think of is, whether we need to warn the user if
attempted to disconnect a subscription which has pre fetched messages, i.e
messages read from the database and which is in the process of writing to
the wire, there might also be subscriptions which has read messages but
have not acknowledged.

Also, IMO if there's a possibility to send a different error code when a
server initiates a disconnection to the client than a network failure error
code, it might be useful to the client to distinguish and write the retry
logic.

Thanks,
Pamod

On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe  wrote:

> I propose,
>  1) user cant disconnect consumers in another nodes. ( simplifies the
> approach).
>  2) there need to be a permission around it.
>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
> whose misbehaving.
>
>
> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:
>
>> Hi Hasitha,
>>
>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
>> implement this feature for MQTT for now. We can consider it when
>> implementing MQTT UI in our major release. WDYT?
>>
>> Thank you,
>> Sajini
>>
>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
>> wrote:
>>
>>> Hi,
>>>
>>> There is a feature request that Message Broker should support to
>>> forcefully disconnect a subscriber. This means, server should be able to
>>> disconnect misbehaving subscribers. Server has a control over it.
>>>
>>> Steps to do this would be
>>>
>>> 1. Find a way to disconnect the socket from mina transport level.
>>> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>>>
>>> At step two the node that is disconnecting  the socket, will broadcast a
>>> Hazelcast message that this subscriber is closed.
>>>
>>> With above implementation steps, a limitation is introduced as "you can
>>> only disconnect the subscribers originated to that node only". For example,
>>> say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
>>> MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
>>> console to disconnect sub2. So cluster aspect is lost there.
>>>
>>> Thus two implementation approaches are there
>>>
>>> 1. Forceful disconnection can be done only from the node subscriber is
>>> connected to.
>>> 2. Forceful disconnection can be done from any node (this is bit
>>> complex. Involves Hazelcast notifications)
>>>
>>> As our end goal for implementation would option 1 be adequate?
>>> Or do we need to reach out for option 2 as well?
>>> Do we need to facilitate this for any subscription type
>>> (queue/topic/durable topic/shared durable topic) ? What about MQTT
>>> subscribers?
>>>
>>> Also what are the permissions a user should have to perform this action?
>>> Are we going to introduce a new permission type?
>>>
>>> Thanks
>>> --
>>> *Hasitha Abeykoon*
>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>>> *cell:* *+94 719363063*
>>> *blog: **abeykoon.blogspot.com* 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sajini De SIlva
>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>> Email: saj...@wso2.com
>> Blog: http://sajinid.blogspot.com/
>> Git hub profile: https://github.com/sajinidesilva
>>
>> Phone: +94 712797729
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> E: ram...@wso2.com
> P: +94 777542851
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Pamod Sylvester *

*WSO2 Inc.; http://wso2.com *
cell: +94 77 7779495
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Ramith Jayasinghe]

I propose,
 1) user cant disconnect consumers in another nodes. ( simplifies the
approach).
 2) there need to be a permission around it.
 3) it could for any subscriber ( may be lets leave out MQTT for a bit)
whose misbehaving.


On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:

> Hi Hasitha,
>
> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
> implement this feature for MQTT for now. We can consider it when
> implementing MQTT UI in our major release. WDYT?
>
> Thank you,
> Sajini
>
> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
> wrote:
>
>> Hi,
>>
>> There is a feature request that Message Broker should support to
>> forcefully disconnect a subscriber. This means, server should be able to
>> disconnect misbehaving subscribers. Server has a control over it.
>>
>> Steps to do this would be
>>
>> 1. Find a way to disconnect the socket from mina transport level.
>> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>>
>> At step two the node that is disconnecting  the socket, will broadcast a
>> Hazelcast message that this subscriber is closed.
>>
>> With above implementation steps, a limitation is introduced as "you can
>> only disconnect the subscribers originated to that node only". For example,
>> say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
>> MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
>> console to disconnect sub2. So cluster aspect is lost there.
>>
>> Thus two implementation approaches are there
>>
>> 1. Forceful disconnection can be done only from the node subscriber is
>> connected to.
>> 2. Forceful disconnection can be done from any node (this is bit complex.
>> Involves Hazelcast notifications)
>>
>> As our end goal for implementation would option 1 be adequate?
>> Or do we need to reach out for option 2 as well?
>> Do we need to facilitate this for any subscription type
>> (queue/topic/durable topic/shared durable topic) ? What about MQTT
>> subscribers?
>>
>> Also what are the permissions a user should have to perform this action?
>> Are we going to introduce a new permission type?
>>
>> Thanks
>> --
>> *Hasitha Abeykoon*
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>> *cell:* *+94 719363063*
>> *blog: **abeykoon.blogspot.com* 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajini De SIlva
> Software Engineer; WSO2 Inc.; http://wso2.com ,
> Email: saj...@wso2.com
> Blog: http://sajinid.blogspot.com/
> Git hub profile: https://github.com/sajinidesilva
>
> Phone: +94 712797729
>
>


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

E: ram...@wso2.com
P: +94 777542851
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Sajini De Silva]

Hi Hasitha,

We haven't implemented the MQTT UI yet. Therefore IMO its better not to
implement this feature for MQTT for now. We can consider it when
implementing MQTT UI in our major release. WDYT?

Thank you,
Sajini

On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya  wrote:

> Hi,
>
> There is a feature request that Message Broker should support to
> forcefully disconnect a subscriber. This means, server should be able to
> disconnect misbehaving subscribers. Server has a control over it.
>
> Steps to do this would be
>
> 1. Find a way to disconnect the socket from mina transport level.
> 2. Send a message to Andes core to delete (disconnect) the subscriber.
>
> At step two the node that is disconnecting  the socket, will broadcast a
> Hazelcast message that this subscriber is closed.
>
> With above implementation steps, a limitation is introduced as "you can
> only disconnect the subscribers originated to that node only". For example,
> say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
> MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
> console to disconnect sub2. So cluster aspect is lost there.
>
> Thus two implementation approaches are there
>
> 1. Forceful disconnection can be done only from the node subscriber is
> connected to.
> 2. Forceful disconnection can be done from any node (this is bit complex.
> Involves Hazelcast notifications)
>
> As our end goal for implementation would option 1 be adequate?
> Or do we need to reach out for option 2 as well?
> Do we need to facilitate this for any subscription type
> (queue/topic/durable topic/shared durable topic) ? What about MQTT
> subscribers?
>
> Also what are the permissions a user should have to perform this action?
> Are we going to introduce a new permission type?
>
> Thanks
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sajini De SIlva
Software Engineer; WSO2 Inc.; http://wso2.com ,
Email: saj...@wso2.com
Blog: http://sajinid.blogspot.com/
Git hub profile: https://github.com/sajinidesilva

Phone: +94 712797729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Forceful queue/topic subscription deletion for Message Broker

[Hasitha Hiranya]

Hi,

There is a feature request that Message Broker should support to forcefully
disconnect a subscriber. This means, server should be able to disconnect
misbehaving subscribers. Server has a control over it.

Steps to do this would be

1. Find a way to disconnect the socket from mina transport level.
2. Send a message to Andes core to delete (disconnect) the subscriber.

At step two the node that is disconnecting  the socket, will broadcast a
Hazelcast message that this subscriber is closed.

With above implementation steps, a limitation is introduced as "you can
only disconnect the subscribers originated to that node only". For example,
say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
console to disconnect sub2. So cluster aspect is lost there.

Thus two implementation approaches are there

1. Forceful disconnection can be done only from the node subscriber is
connected to.
2. Forceful disconnection can be done from any node (this is bit complex.
Involves Hazelcast notifications)

As our end goal for implementation would option 1 be adequate?
Or do we need to reach out for option 2 as well?
Do we need to facilitate this for any subscription type
(queue/topic/durable topic/shared durable topic) ? What about MQTT
subscribers?

Also what are the permissions a user should have to perform this action?
Are we going to introduce a new permission type?

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