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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sajini De SIlva > Software Engineer; WSO2 Inc.; http://wso2.com , > Email: [email protected] > 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: [email protected] P: +94 777542851
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
