Petals ESB Container

As a new distributed registry, based on Hazelcast, has been introduced with Petals ESB 5.0.0, this issue will not be fixed.

I'm agree with you: the "registry" name is just a shortcut to talk about the global registry subject into the esb, mainly drived by the kernel. So it's the global architectural philosophy of what's an esb registry, and what to put (and not put!) in that have to be done one day...
We've got any powerful hibernate controlled databases, with great performance and robustness (not excellent of course, it always will be less efficent that a database kind dedicated layer "hand-made"! Wrapping running...). So the hibernate layer can be kept, but a refactoring is needed to improve and fix already found bugs.
My 20 cents...

The registry implementation is not completely out of the kernel. Some implementation classes are always present in the kernel. In the kernel, it should remain only the Registry interface.

For example, if I want to implement a registry based on a DHT framework as Hazelcast, I don't need remaining implementation classes.

"getting the registry implementation out of the kernel"

I do not understand what it means. The registry implementation is already out of the kernel. The kernel only has a small facade implementation to map the JBI API to registry API ie activateEndpoint(ep) -> registry.add(ep), deactivateEndpoint(ep) -> registry.delete(ep) for example

I agree with you Christophe. The registry rework consists in:

• improving the registry itself,
• reviewing its usage by the kernel,
• getting the registry implementation out of the kernel

The problem is not in the registry itself but on how the registry is used by the petals kernel ie The kernel component which is in charge in initializing the registry instance or stopping it also calls some reset methods provided by the registry implementation to clean data when the node starts, stops, ...

I'm agree: we've got a lot of issue with the current registry. Delete all et recreate all at each start/stop container action is better than let all today, in term of global robustness (less of installation corruption seen...)
Yes, let's rework the registry .

Analyzing the problem in greater depth, we can see the following problem:

• Endpoints are unregistered when stopping the container. IMO, a endpoint should be unregistered only when its service is undeployed or its component is uninstalled. Ans so, messages should be queued until the endpoint becomes available again.
• Endpoints are unregistered when closing the delivery channel of their component. When closing the delivery channel, only messages should be stopped

In view of the fact that the initial problem is only a log size problem without other side-effects, in view of the risk of fixing these problems in a maintenance release, this issue will be taken into account with the rework of the registry.

I reproduce the problem with the following steps:

1. Start a Petals ESB node
2. Install a component
3. Deploy a service provider
4. Delete the endpoint of the service provider into the registry database
5. Stop the Petals ESB node using the script 'stop.sh'
6. The stack trace previously mentioned occurs

If the database is stop during the stop of the container, you will get a stack trace similar to the following:

[Petals.Container.ComponentLifeCycle.petals-bc-soap]-SEVERE 2011-05-03 16:52:45,690 Failed to stop the component 'petals-bc-soap'
javax.jbi.messaging.MessagingException: org.ow2.petals.jbi.messaging.registry.RegistryException: could not execute query
	at org.ow2.petals.jbi.messaging.exchange.DeliveryChannelImpl.close(DeliveryChannelImpl.java:169)
	at org.ow2.petals.container.lifecycle.ComponentLifeCycle.doShutdown(ComponentLifeCycle.java:187)
	at org.ow2.petals.container.lifecycle.ComponentLifeCycle.stopComponentLifeCycle(ComponentLifeCycle.java:327)
	at org.ow2.petals.container.lifecycle.ComponentLifeCycle.stopFc(ComponentLifeCycle.java)
	at org.objectweb.fractal.julia.generated.Cbd2013d7_0.setFcContentState(BasicControllerMixin.java:8130)
	at org.objectweb.fractal.julia.generated.Cbd2013d7_0.setFcStopped(BasicControllerMixin.java:8087)
	at org.objectweb.fractal.julia.generated.C18c4c884_0.setFcStopped(INTERFACE[LifeCycleCoordinator])
	at org.objectweb.fractal.julia.generated.Cbd2013d7_0.stopFc(BasicControllerMixin.java:3187)
	at org.objectweb.fractal.julia.generated.Cbd2013d7_0.stopFc(BasicControllerMixin.java:4131)
	at org.objectweb.fractal.julia.generated.C18c4c884_0.stopFc(INTERFACE[LifeCycleCoordinator])
	at org.ow2.petals.kernel.server.FractalHelper.stopComponent(FractalHelper.java:379)
	at org.ow2.petals.kernel.server.PetalsServerImpl.stopPetalsComposite(PetalsServerImpl.java:508)
	at org.ow2.petals.kernel.server.PetalsServerImpl.stop(PetalsServerImpl.java:220)
	at org.ow2.petals.kernel.server.PetalsStopThread.run(PetalsStopThread.java:49)
Caused by: org.ow2.petals.jbi.messaging.registry.RegistryException: could not execute query
	at org.ow2.petals.jbi.messaging.registry.BaseEndpointRegistry.deactivateEndpoint(BaseEndpointRegistry.java:177)
	at org.objectweb.fractal.julia.generated.C2304ecde_0.deactivateEndpoint(INTERCEPTOR[EndpointRegistry])
	at org.objectweb.fractal.julia.generated.C2eb804c9_0.deactivateEndpoint(INTERFACE[EndpointRegistry])
	at org.ow2.petals.jbi.component.context.ComponentContextImpl.deregisterAllEndpoints(ComponentContextImpl.java:248)
	at org.ow2.petals.jbi.messaging.exchange.DeliveryChannelImpl.close(DeliveryChannelImpl.java:167)
	... 13 more