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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
