Hi Senaka, Just a thought ;-). This notifications basically meant to provide what happen to the repository and I would say it is NOT for registry. If I subscribe to an update event for a service, I only interested in a notification where I am notified ONLY when the particular service is updated. Hence, why can't we trigger the events from the Repository layer ?
On Tue, Aug 19, 2014 at 3:03 AM, Senaka Fernando <[email protected]> wrote: > Hi Danesh, > > I also think #4 is proper. This is the way we track transaction > commit/rollback status as well, so if you take a look @ the semantics of > commit, this should be similar. So, ideally every supposedly unit > operation, which happens to invoke other operations will increment the > counter before invoking the subsequent operation and decrement the counter > after it completes. This approach however, needs to be done @ every > handler, component, kernel etc. > > Suggestion 05: > Another trick though I'm not sure about the possibility is to track the > transaction depth counter. This counter too will have information as to how > far deep you are inside a transaction. Which is similar to the counter you > are talking about. One catch is that the mount handler pushes this counter > into a stack when it goes into a JDBC mount to make it possible to have > transactions across DBs. To handle this AFAIU, you can also check whether > the mount handler's stack is empty or not. But, I don't see it to be good > idea to have this accessed outside of the kernel, so may be introduce a > method inside the Transaction API of the kernel to explain whether you are > within the terminal operation of a nested query or whether you are infact > inside a nested operation. > > Thanks, > Senaka. > > > On Mon, Aug 18, 2014 at 8:05 PM, Danesh Kuruppu <[email protected]> wrote: > >> Hi Senaka, >> Earlier we had an idea of having a flag and problem was how we could >> handle the flag inside multiple request. >> Suggestions we had earlier, >> >> Suggestion 01: Keep a flag in requestContext to track event firing. >> *This is impossible because inside one request, there are multiple >> requests and each request trigger eventing handler.* >> >> Suggestion 02: Keep a ThreadLocal flag to track event firing. >> *Problem with this is we couldn't clearing identify the boundaries of one >> user request. We need to put the flag down at the end of the request which >> we couldn't find easily. * >> >> Suggestion 03: Keep a flag in requestContext and whenever new request >> create inside the main request, transfer the flag status of the previous >> request to the new request. transferor is a threadlocal variable. Here each >> time we invoke registry call, we set the value of the threadlocal variable >> to the current flag status of the requestContext and inside registry call >> we set the flag value of the new requestContext to the value in threadLocal >> variable. >> >> *This is too complex solution. we need to find out all registry call and >> set the variable manually.* >> Suggestion 04 : Keep a threadLocal stack to track the request flow. Here >> each time we create request, we put it in the stack and at the end of the >> registry call we remove that request from the stack. typical request flow >> e.g.: >> >> Put | Add Request >> Stack Size >> 1 >>> Put | Add Request >> Stack Size >> 2 >>> Remove Association | Add Request >> Stack Size >> 3 >>> Remove Association | Remove Request >> Stack Size >> 3 >>> Remove Association | Add Request >> Stack Size >> 3 >>> Put | Add Request >> Stack Size >> 4 >>> Put | Remove Request >> Stack Size >> 4 >>> Remove Association | Remove Request >> Stack Size >> 3 >>> Put | Add Request >> Stack Size >> 3 >>> Put | Remove Request >> Stack Size >> 3 >>> Add Association | Add Request >> Stack Size >> 3 >>> Add Association | Remove Request >> Stack Size >> 3 >>> Put | Remove Request >> Stack Size >> 2 >>> Put | Remove Request >> Stack Size >> 1 >>> >> >> the Stack size reach the zero means we are at the end of the user >> request. we can trigger eventing handler to generate notification. >> *Currently this works for me, but don't know whether this is a feasible >> solution.* >> >> Thanks >> >> >> On Mon, Aug 18, 2014 at 6:25 PM, Senaka Fernando <[email protected]> wrote: >> >>> Hi Eranda, >>> >>> Alright. So, just stop the duplication. Ideally, the handler should only >>> be triggered once. And, AFAIU, this is doable with the association-update >>> and recursive delete handlers (and other utility handlers of similar sort) >>> can set some flag within themselves preventing the eventing handlers from >>> firing events for those. Won't this work? >>> >>> Thanks, >>> Senaka. >>> >>> >>> On Mon, Aug 18, 2014 at 1:42 PM, Eranda Sooriyabandara <[email protected]> >>> wrote: >>> >>>> Hi Senaka, >>>> Requirement here is that when we do a artifact update the subscriber >>>> getting massive number of mails saying resource updated where the number >>>> depends on the number of associations and properties/hidden properties. >>>> >>>> thanks >>>> Eranda >>>> >>>> >>>> On Mon, Aug 18, 2014 at 6:02 PM, Senaka Fernando <[email protected]> >>>> wrote: >>>> >>>>> Hi Danesh, Eranda, >>>>> >>>>> I think we are doing too much here. Before going ahead with this kind >>>>> of different subscription model, we need to understand the requirement >>>>> here. At least I'm not clear on that. Do you want it to be configurable as >>>>> to whether people want to subscribe for association updates etc? or do you >>>>> want to simply stop people getting multiple notifications? >>>>> >>>>> Also, we cannot literally get rid of the handler approach. Its either >>>>> a handler or it has to be burnt into the kernel. I personally don't think >>>>> the kernel needs this massive feature and if we take that approach we'll >>>>> be >>>>> tailoring the kernel to suit components. But, lets try to clarify the >>>>> above >>>>> before trying to do anything new. >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> >>>>> On Mon, Aug 18, 2014 at 1:28 PM, Eranda Sooriyabandara < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Senaka, >>>>>> >>>>>> >>>>>> On Mon, Aug 18, 2014 at 5:26 PM, Danesh Kuruppu <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Senaka, >>>>>>> >>>>>>> In the current system, event capturing is done through handlers. We >>>>>>> couldn't come up with a solution through handlers. >>>>>>> >>>>>>> >>>>>> As we went through the code and the complexity of change should be >>>>>> done in order to achieve this with the RegistryEventHandler and the >>>>>> handler >>>>>> architecture is bit complected. Hence we thought of go for a different >>>>>> solution where we introduce a new subscription type in governance level >>>>>> and >>>>>> we allow subscribe in artifact listing page where other subscriptions >>>>>> will >>>>>> remain the same. As Danesh's figure we will do subscribing and >>>>>> unsubscribing using the list view. >>>>>> We understand that this will complicate the list view but if we add >>>>>> this in the resource level then the normal subscription story will break. >>>>>> There will be complications with the following areas. >>>>>> >>>>>> 1. How to show different event and notification types. We are >>>>>> planning to have a pop-up which has the similar view as our normal >>>>>> subscription >>>>>> 2. Managing existing subscriptions. As I mentioned in 1 since we >>>>>> use the similar view as our normal subscription it will come with the >>>>>> view >>>>>> and delete option for existing subscription. >>>>>> >>>>>> Also there is a problem of notifying in governance API since >>>>>> governance API can be use as a client library, need to find a solution. >>>>>> >>>>>> thanks >>>>>> Eranda >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Current suggested solution is, >>>>>>> >>>>>>> We are giving another subscribe button in artifact level(in List >>>>>>> view) which is used for subscribe Artifact update and delete [Please >>>>>>> find >>>>>>> the attached screenshot]. other subscriptions(check/uncheck LC, remove >>>>>>> LC, >>>>>>> approve LC etc) are not going to change and are done in resource level. >>>>>>> So user can subscribe to update and delete notifications in Artifact >>>>>>> level and they will handle separately. >>>>>>> >>>>>>> Please give feedback on this. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 15, 2014 at 8:50 PM, Shavantha Weerasinghe < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Danesh >>>>>>>> >>>>>>>> For notifications cant we have an option where the user gets to >>>>>>>> select which group of resources user wants to update by ticking to >>>>>>>> enable >>>>>>>> and generate notifications for only that area. >>>>>>>> >>>>>>>> Will that be extra work for the user >>>>>>>> >>>>>>>> Regards >>>>>>>> On Aug 15, 2014 6:09 PM, "Senaka Fernando" <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Danesh, >>>>>>>>> >>>>>>>>> Yes, this is problem that we need to fix. >>>>>>>>> >>>>>>>>> I think we need to find a way to mask notifications for certain >>>>>>>>> operations. Ideally the association processing is a part of the >>>>>>>>> update and >>>>>>>>> doesn't require separate notifications. But, this functionality of >>>>>>>>> masking >>>>>>>>> should not just be specific to this use-case, but generically usable >>>>>>>>> for >>>>>>>>> any similar scenario. Before having the call, can you do some >>>>>>>>> research and >>>>>>>>> propose a solution to this? Based on that, lets discuss. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Senaka. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 15, 2014 at 1:11 PM, Danesh Kuruppu <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Senaka, >>>>>>>>>> >>>>>>>>>> With the current implementation, If user subscribe to a resource >>>>>>>>>> which have multiple associations attached to it, user will receive >>>>>>>>>> multiple >>>>>>>>>> update notifications for a single update. >>>>>>>>>> >>>>>>>>>> This is because resource update have multiple repository update >>>>>>>>>> and for every repository update system generates update notification. >>>>>>>>>> >>>>>>>>>> We need to find a way to send single update notification for >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> Can we have a call on this please. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Danesh Kuruppu >>>>>>>>>> Software Engineer >>>>>>>>>> WSO2 Inc, >>>>>>>>>> Mobile: +94 (77) 1690552 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>>>>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * Member; Apache Software Foundation; http://apache.org >>>>>>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>>>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>>> >>>>>>>>> >>>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>>>>>> http://linkedin.com/in/senakafernando >>>>>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . >>>>>>>>> Middleware >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Danesh Kuruppu >>>>>>> Software Engineer >>>>>>> WSO2 Inc, >>>>>>> Mobile: +94 (77) 1690552 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>>>> Integration Technologies Team; >>>>>> WSO2 Inc.; http://wso2.com >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> E-mail: eranda AT wso2.com >>>>>> Mobile: +94 716 472 816 >>>>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>>>> Blog: http://emsooriyabandara.blogspot.com/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>> >>>>> >>>>> >>>>> * Member; Apache Software Foundation; http://apache.org >>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>> >>>>> >>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>> http://linkedin.com/in/senakafernando >>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>> Integration Technologies Team; >>>> WSO2 Inc.; http://wso2.com >>>> Lean . Enterprise . Middleware >>>> >>>> E-mail: eranda AT wso2.com >>>> Mobile: +94 716 472 816 >>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>> Blog: http://emsooriyabandara.blogspot.com/ >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>> Software Architect; WSO2 Inc.; http://wso2.com >>> >>> >>> >>> * Member; Apache Software Foundation; http://apache.org >>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>> >>> >>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>> http://linkedin.com/in/senakafernando >>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>> >> >> >> >> -- >> >> Danesh Kuruppu >> Software Engineer >> WSO2 Inc, >> Mobile: +94 (77) 1690552 >> > > > > -- > > > *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* > Software Architect; WSO2 Inc.; http://wso2.com > > > > * Member; Apache Software Foundation; http://apache.org > <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 > 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; > > > *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: > http://linkedin.com/in/senakafernando > <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware > -- Thanks /subash *Subash Chaturanga* Senior Software Engineer & Lead WSO2 Governance Registry Platform TG; WSO2 Inc. http://wso2.com Contact: email: [email protected] blog: http://subashsdm.blogspot.com/ twitter: @subash89 phone: +9477 2225922 Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
