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