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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >>> 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 >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *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
