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

Nicolas Filotto nicolas.filotto at exoplatform.com
Thu Nov 14 10:01:17 EST 2013


No there is no bug, it is expected to ensure consistency on shutdown


On Thu, Nov 14, 2013 at 2:45 PM, Juraci Paixão Kröhling
<jcosta at redhat.com>wrote:

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


More information about the gatein-dev mailing list