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

[Nicolas Filotto]

To be able to understand that you need to understand how the kernel works,
did you check it?


On Mon, Nov 11, 2013 at 2:54 PM, Juraci Paixão Kröhling
<jcosta at redhat.com>wrote:

> Nicolas,
>
> Thanks for your answer! Based on your suggestion, I'm now able to check
> the state of the repository via RepositoryService before letting an
> exception be thrown down the road. It helps me to prevent the WARN
> message, which is the target of the JIRA I mentioned. And even though it
> doesn't allows me to properly shut down WSRP, it at least let me have
> the same behaviour as today.
>
> But it's still a bit confusing to me as to why the RepositoryContainer
> is added to the bottom of the "start" list.
>
> For clarity, I've added two lists on pastebin:
>
> http://pastebin.com/Ba4GBdhF
> http://pastebin.com/VuDUGiWg
>
> The first is the list of services to be started as seen on
> LifecycleVisitor, at around the same step as the WSRP service is
> started. The second is the same thing, but for the stop operation.
>
> By looking at the code, I would expect the lists to be exactly the same,
> just the "stop" list being the reverse of the "start", but note that
> there's an extra RepositoryContainer there on the "stop" list, right at
> the top, meaning that it's the first one of the list to be stopped.
>
> Adding RepositoryService to the constructor didn't help shift the
> RepositoryContainer down the list, as RepositoryService is indeed being
> started before everything and stopped after everything. Also, it seems
> that RepositoryContainer is not a candidate for being injected.
>
> From your explanation, I would expect RepositoryContainer to not show up
> on the "stop" list (as it's started on a different nesting level from
> those services), or at least be near to the RepositoryServiceImpl, which
> is not the case.
>
> Regards,
> Juca.
>
>
> On 11/11/2013 09:33 AM, Nicolas Filotto wrote:
> > Hi,
> >
> > RepositoryContainer and Workspace containers are created, initialized and
> > started by the RepositoryService. Try to add explicitly the
> > RepositoryService in your constructor, this way your component should be
> > started after the RepositoryService (and the RepositoryContainer) and
> will
> > be stopped before the RepositoryService. Another solution would be to
> check
> > the state of the repository first using
> > RepositoryService.getCurrentRepository().getState() (warning it is not a
> > static call, the goal is only to show you the methods to call), you need
> to
> > make that the value is ManageableRepository.ONLINE
> >
> > BR,
> > Nicolas
> >
> >
> > On Fri, Nov 8, 2013 at 12:22 PM, Juraci Paixão Kröhling
> > <jcosta at redhat.com>wrote:
> >
> >> All,
> >>
> >> I'm currently working on GTNPORTAL-3281 [1], and I have a question.
> >>
> >> The WARN message on the logs occurs during the shutdown of the server,
> >> when the method WSRPServiceIntegration.stop() is called. During this
> >> stop() method, both producer and consumers are then requested to be
> >> stopped, but the configuration for the producer and the list of
> >> consumers requires access to the workspace, which is already shut down,
> >> as RepositoryContainer is stopped before WSRPServiceIntegration.
> >>
> >> While stopping the producer is possible without requesting the workspace
> >> to be active, shutting down the consumers currently require a fresh list
> >> of consumers, which in turn requires access to the workspace.
> >>
> >> When looking into why WSRPServiceIntegration is stopped after
> >> RepositoryContainer, I noticed that the list of services to start during
> >> the boot contains 36 items, while the shutdown contains 37. The
> >> difference is exactly the RepositoryContainer.
> >>
> >> So, does anyone knows if it is appropriate for RepositoryContainer to be
> >> stopped before everything else, including WSRPServiceIntegration? If
> >> not, I would then look for the place where RepositoryContainer is added
> >> and add it to the head of the list, instead of appending it (this means
> >> that RepositoryContainer will be the last thing to be stopped, instead
> >> of the first, as it currently is).
> >>
> >> If RepositoryContainer should indeed be the first thing to be shut down,
> >> then the solution that I can see is to get the cached list of consumers,
> >> instead of getting a fresh one. This should remove the requirement of
> >> the workspace to exist during the shutdown of WSRPServiceIntegration.
> >>
> >> 1 - https://issues.jboss.org/browse/GTNPORTAL-3281
> >>
> >> Thanks!
> >> Juca.
> >> _______________________________________________
> >> gatein-dev mailing list
> >> gatein-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/gatein-dev
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20131111/eb40035a/attachment.html