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

[Nicolas Filotto]

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>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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20131112/fe1cf4fa/attachment.html