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 <[email protected]> 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 <[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 > > -- ============================ 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
