[gatein-dev] RepositoryContainer as the first thing to stop during shutdown

[Juraci Paixão Kröhling]

Hello Nicolas,

I would like to thank you for the links and information you sent. It was
very useful!

I spent some more time in debugging and reading the documentation, but I
can't help and wonder if I'm not hitting a bug on the stop() method for
RepositoryContainer.

See, the start() method initializes itself and then starts the dependent
components, by calling super.start(). I would expect the reverse
behaviour on the stop method, in that it stops all components and then
stop itself, but that's not what's happening:

http://git.io/hfnATA

Making it to be the reverse logic as the start() method seems to indeed
fix the issue with the WSRP component during shutdown:

Shutdown logs for the current behaviour:
http://pastebin.com/g5vNrbPJ

Shutdown logs for the patched code:
http://pastebin.com/FYcr5zbK

If this is indeed a bug, I can send a PR with the following commit:

http://git.io/ZbZNXg

Regards,
Juca.


On 11/12/2013 11:07 AM, Nicolas Filotto wrote:
> Generally speaking the doc of eXo JCR is hosted on your web site
> here http://www.jboss.org/exojcr/documentation
> 
> We don't have any doc that describes how the kernel works as it is
> implementation specific and it could change from one version to another.
> For example with the new multi-threaded kernel, the way it is done, is
> already different from the current kernel. What I meant by "did you
> check it?", I meant : did you check the code?
> 
> Let me try to explain simply without getting into too much details (if I
> can).
> 
> In your configuration files, you define all the components. According to
> the location of those files, they can be affected either to the
> RootContainer or to the PortalContainer(s) in case of the portal mode
> which is the mode used by Gatein. In case of the standalone mode, they
> will be affected to the StandaloneContainer. All those containers are
> ExoContainers, when you start an ExoContainer behind the scene it first
> gets all the components of type Startable, then it instantiates them,
> and finally it starts them. Any time a component is instantiated it is
> added to a List. This List will be used to define the startup sequence.
> It will also be used to define the shutdown sequence by reversing it.
> 
> To make it clear, let's give an example, let's say that we have A that
> depends on B and B that depends on C, and A and C are Startable.
> The kernel gets all the components of type Startable, so it gets A and
> C. Then it tries to instantiate them, so first it will try to
> instantiate A but for that it will need to instantiate C because of B,
> so the first element in the list will be C, then B, then A. To get our
> startup sequence we keep only the Startable components of this List, so
> we will have only C and A. So it will first start C then A, and will
> stop A then C.
> 
> So far, I believe that it was clear for you, the use case that you
> mention is actually a specific one. In the hierarchy of ExoContainers
> (in portal more), we have first the RootContainer, then we can have one
> or more PortalContainer(s), then we can have one or more
> RepositoryContainer(s) (we have one RepositoryContainer per repository)
> and finally we can have one or more WorkspaceContainer(s) (we have one
> WorkspaceContainer per workspace). The PortalContainers are created by
> the RootContainer and the RepositoryContainer(s)/WorkspaceContainer(s)
> are created, initialized and started by the RepositoryService at startup.
> 
> Why do I see the RepositoryContainer in the shutdown sequence ?
> Because the RepositoryContainer is added to the PortalContainer and an
> ExoContainer is Startable
> 
> Why the RepositoryContainer is the first element in the shutdown sequence ?
> Because it is added in the startup phase so all the Startable components
> are already instantiated and added to the List that defines the startup
> sequence, which means that it will be the last element in the List so
> the first element to be stopped
> 
> Why I don't see the RepositoryContainer in the startup sequence?
> Because it is added after by the RepositoryService in the startup phase
> 
> Why do you create/initialize/start the RepositoryContainer in the start
> method of RepositoryService?
> Because this service depends on component plugins, so we need to be sure
> that we have all of them before creating the repositories and the
> workspaces which is only possible in the start method
> 
> I hope it is clear enough now
> 
> 
> On Tue, Nov 12, 2013 at 8:59 AM, Juraci Paixão Kröhling
> <jcosta at redhat.com <mailto:jcosta at redhat.com>> wrote:
> 
>     On 11/11/2013 05:47 PM, Nicolas Filotto wrote:
>     > To be able to understand that you need to understand how the kernel
>     > works, did you check it?
> 
>     To be honest, I couldn't find much information about how the kernel
>     works, other than the overview in the reference guide and by looking at
>     the code, with a debugger attached :-) I'm trying to read as much as I
>     can, but it seems that the information for contributors is spread in
>     some places and not following some structure, making it a bit hard to
>     put the things together.
> 
>     If you could suggest some particular reading or approach, I'd
>     appreciate!
> 
>     Thanks,
>     Juca.
> 
>