Hi Udara, We will mention this behavior clearly in the documentation such that users are not confused.
Thanks, Chanaka On Tue, Feb 24, 2015 at 1:53 PM, Udara Liyanage <[email protected]> wrote: > Hi Chanaka, > > > > On Tue, Feb 24, 2015 at 11:33 AM, Chanaka Fernando <[email protected]> > wrote: > >> Hi Udara, >> >> Thanks for your feedback. Actually the real reason for the first approach >> is not the easiness of the implementation. It is about consistency across >> CAR deployment and file artifact deployment. If we go with the second >> approach, it will behave in 2 different ways. >> > Yes I agree with you > However what I want to point out is users might get confused when servers > start differently after restart > >> >> Thanks, >> Chanaka >> >> On Tue, Feb 24, 2015 at 11:13 AM, Udara Liyanage <[email protected]> wrote: >> >>> Hi Chanaka, >>> >>> Sorry if I am providing my suggestions too late. >>> >>> From the point of view of implementation aspect first approach is easy. >>> However from users point of view second option is the desired option. Users >>> may get confused when they see different results when they restart the >>> server, for instance say an deactivated MP starts processing messages >>> immediately and other way around too. >>> >>> On Tue, Feb 24, 2015 at 9:39 AM, Isuru Udana <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Feb 24, 2015 at 9:37 AM, Shafreen Anfar <[email protected]> >>>> wrote: >>>> >>>>> Hi Guys, >>>>> >>>>> Back to Chanaka's original discussion :). +1 for the first option. If >>>>> one wants deactivate the MP and persist it, he can simply do it by editing >>>>> the MP and setting the value rather than using the deactivation button. >>>>> >>>> +1. We already agreed (offline) to implement like that :) >>>> >>>>> >>>>> On Wed, Feb 18, 2015 at 2:50 PM, Anjana Fernando <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Ravindra, >>>>>> >>>>>> I'm not sure, if you and Chanaka are talking about the same thing. >>>>>> Chanaka mainly talked about the scenario that happens in the case of CAR >>>>>> deployment, where that is the know behavior when we deploy things from >>>>>> CAR, >>>>>> so any change you do locally, will be lost the next time, which is why >>>>>> you >>>>>> need to have the changes in the CAR itself. >>>>>> >>>>>> As for the state transition events, in these situations what we do >>>>>> is, we simply sent out cluster messages to the interested parties. So >>>>>> they >>>>>> know what is going on with a node on the cluster, and they are notified. >>>>>> This functionality is already there in the platform, and it is not >>>>>> something that needs to be handled in ntask. >>>>>> >>>>>> Cheers, >>>>>> Anjana. >>>>>> >>>>>> On Wed, Feb 18, 2015 at 4:15 PM, Ravindra Ranwala <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Currently when the Message Processor states are changed via ESB >>>>>>> management console in a cluster mode, the states are synchronized using >>>>>>> the >>>>>>> dep-sync mechanism. Automatic deactivation is the only scenario where >>>>>>> the >>>>>>> dep-sync is not used to synchronize the states of the message processor >>>>>>> across the worker nodes of the cluster. >>>>>>> >>>>>>> If we are avoiding dep-sync, we need to have an event based support >>>>>>> in ntask core (platform) so that we can subscribe to state transition >>>>>>> events of a given task. The other alternative is to have a Polling based >>>>>>> scheme, which will be a costly solution and consumes more CPU cycles. >>>>>>> AFAIK, currently there is no such an event driven support in ntask core >>>>>>> and >>>>>>> what we have is a polling based scheme. >>>>>>> >>>>>>> @Anjana: Could you please let us know whether this is feasible. >>>>>>> >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> >>>>>>> On Wed, Feb 18, 2015 at 3:22 PM, Chanaka Fernando <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> We are currently revamping the Message Processor implementation to >>>>>>>> provide coordination support in a clustered environment using ntask >>>>>>>> implementation. During this process we are planning to resolve a long >>>>>>>> running issue in the Message Processor usage. The issue is that, when >>>>>>>> we >>>>>>>> deploy a Message processor in the ESB and try to change the status >>>>>>>> (activate/deactivate), it will change the xml file and persist that >>>>>>>> state >>>>>>>> in to that file. This behavior causing issues when we deploy MP using >>>>>>>> a CAR >>>>>>>> file since it does not deploy the xml file in to deployment directory >>>>>>>> by >>>>>>>> default. When this happens, if we change the MP from management >>>>>>>> console, it >>>>>>>> will save the xml and throw errors when restarting the server and the >>>>>>>> status is not persisted. >>>>>>>> >>>>>>>> Our initial plan was to not persist the active/deactive state in >>>>>>>> the file but keep that state in the memory. When a user change the >>>>>>>> status >>>>>>>> from the management console, it will not persist in the xml file but >>>>>>>> change >>>>>>>> the status in the memory and MP will change the status accordingly. The >>>>>>>> drawback with this model is that we cannot persist the state of the MP >>>>>>>> (which we have changed) after a server restart. >>>>>>>> >>>>>>>> Another option is to check whether the artifact is coming from a >>>>>>>> CAR file or not and persist the state only if it is not coming from a >>>>>>>> CAR >>>>>>>> file. But even with this approach, we can only persist the state of the >>>>>>>> processor for artifacts which are not deployed from the CAR file. >>>>>>>> >>>>>>>> Given the above options, I think the first option is more >>>>>>>> consistent since it would not behave differently for artifacts coming >>>>>>>> from >>>>>>>> different paths. The drawback with that is we can't persist the state >>>>>>>> of >>>>>>>> the MP (which has changed during the server runtime) after server >>>>>>>> restart. >>>>>>>> If some user needs to persist the status, he may need to change the CAR >>>>>>>> file with the desired state. >>>>>>>> >>>>>>>> Any suggestions would be welcomed. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Chanaka >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Chanaka Fernando >>>>>>>> Technical Lead >>>>>>>> WSO2, Inc.; http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> mobile: +94 773337238 >>>>>>>> Blog : http://soatutorials.blogspot.com >>>>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>>>>>> Twitter:https://twitter.com/chanakaudaya >>>>>>>> Wordpress:http://chanakaudaya.wordpress.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ravindra Ranwala >>>>>>> Software Engineer >>>>>>> WSO2, Inc: http://wso2.com >>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>>>> Mobile: +94714198770 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Anjana Fernando* >>>>>> Senior Technical Lead >>>>>> WSO2 Inc. | http://wso2.com >>>>>> lean . enterprise . middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> *Shafreen* >>>>> Software Engineer >>>>> WSO2 Inc >>>>> Mobile : 077-556-395-1 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Isuru Udana* >>>> Senior >>>> *Software Engineer* >>>> WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 3791887 >>>> blog: http://mytecheye.blogspot.com/ >>>> twitter: http://twitter.com/isudana >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> >>> Udara Liyanage >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean. enterprise. middleware >>> >>> web: http://udaraliyanage.wordpress.com >>> phone: +94 71 443 6897 >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> -- >> Chanaka Fernando >> Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> > > > -- > > Udara Liyanage > Software Engineer > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > web: http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > -- -- Chanaka Fernando Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 773337238 Blog : http://soatutorials.blogspot.com LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 Twitter:https://twitter.com/chanakaudaya Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
