+1 I would even say stronger "...we MUST give a way..."
Best regards, Frank 2015-12-03 11:01 GMT+01:00 Srinath Perera <srin...@wso2.com>: > 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 <ram...@wso2.com> > 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 <saj...@wso2.com> 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 <hasit...@wso2.com> >>> 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* <http://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
