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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

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(a)redhat.com&gt;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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >

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.

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(a)redhat.com <mailto:jcosta@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. > >

On 11/14/2013 04:01 PM, Nicolas Filotto wrote: > No there is no bug, it is expected to ensure consistency on shutdown In that case, I'd have to ask if there would be another event or hook that I could subscribe to get notified before the repository gets offline. That's because WSRP needs a fresh list of the consumers running on the portal that is being shutdown, so that they are unregistered[1]. This list of consumers comes from the persistent storage[2], meaning that it needs to open a Chromattic session, which in turn needs the repository to be online[3]. While I can certainly workaround it using a cached list of consumers to unregister from the federating portlet invoker, I would rather prefer to be notified about a last chance to talk to the persistent storage. From what I'm understanding from this thread, when the stop() method is called for WSRP, it's already too late to properly stop WSRP, but perhaps there's another notification that I should be listening to? How do other components deals with this scenario (getting something from persistent storage during shutdown)? 1 - http://git.io/ujAGbQ 2 - http://git.io/2B3kLA 3 - http://git.io/yiYuCw Thanks! Juca.