On Tue, Feb 24, 2015 at 9:37 AM, Shafreen Anfar <shafr...@wso2.com> 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 <anj...@wso2.com> 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 <ravin...@wso2.com> >> 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 <chana...@wso2.com> >>> 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: isu...@wso2.com cell: +94 77 3791887 blog: http://mytecheye.blogspot.com/ twitter: http://twitter.com/isudana
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
