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