[Users] Difficulties during recovery

rnaudin petals-use at ebmwebsourcing.com
Wed Mar 16 10:27:20 CET 2011


We you stop PEtALS (and not Shutdown), PEtALS tries to stop the components that are running(started) , in order to stop properly the connections established by them before stopping the container.
However, the state of the component stay started in the repository, in order to be able to recover them at the next restart.

When changing the state of a component (start -> stop -> shutdown...) or a SA, if the process fails, PEtAlS tries to return to the previous state. BUT, if the rollback fails too, PEtALS set the component to UNKNOWN state, as it cannot know which stable state can be assign to the component life-cycle.
Then, we you stop and restart your container, the component are keep in an unknown state until an operation on its lifecycle is processed, note that a warning message should appears in the traces about its UNKNOWN state.
For SAs, the same mechanism is applied. However it's much more complex with SAs as they can contain several SUs. So when a SA failed to change of life-cycle state, PEtALS tries to rollback to the previous state only the SUs that have successfully changed their state. If it fails to rollback, you will have some SUs in a state and others in and UNKNOWN state...A mess.

 [Arrow] Why SHUTDOWN seems to work better? Because shutdown called the forcing methods to undeploy and uninstall all the SAs/components. Once you have remove all installed JBI artifact, you can reinstall/deploy everything.

 [Exclamation] Most people forget that there is in JBI different phases in the life of JBI artifacts. A JBI component has an installer, which then install the component. Once the component installed, it can be start/stop/shutdown. A SA can be deploy/start/stop/shutdown/undeploy. Check the JBi specification for more details about that.
A JBI container must propose an installer and a deployer service accessible via JMX in order to do that. That's what PEtALS proposes.
These services can be invoked via a Jconsole or via a ant script, which relies on the petals-ant library. These petals-ant library relies at its turn on the PEtALs JMX services.

 [Question] We have introduce facilities in PEtALS to manage the JBI artifact installation/deploiment, like the directory based autoloader, which invokes successively the several step to have the component or the SA running. We propose too a web console which warps the JMX invocations. However the web console does not included all the JMX methods, such as the forcing methods to undeploy/uninstall.

 [Idea] What to do when you have unknown states? Try to restart first the components, then the SAs via JMX or scripts based on ant.

 [Question] What we can improve? the robustness of fail-over on life-cycles of JBI artifact, and a deidacted JMX method (probably in the PetalsAdmin JMX service) to clean the repository properly when a JBI artifact is totally corrupted (resources missing, corrupted files...).

Hopes it's much clear, but maybe less [Twisted Evil] 
/Roland




-------------------- m2f --------------------

Read this forum topic online here:
http://petals.ebmwebsourcing.com/forum/viewtopic.php?p=452#452

-------------------- m2f --------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum-list.petalslink.org/pipermail/users/attachments/20110316/5665b4e3/attachment.htm>


More information about the Users mailing list