On Tue, Sep 23, 2014 at 11:48 PM, [email protected] <[email protected]> wrote: > Hi devs, > > Right now there’s a problem when XWiki is shutdown. This is what currently > happens: > > 2014-09-23 13:54:05,563 [Thread-1] DEBUG o.x.shutdown - > Starting XWiki shutdown... > 2014-09-23 13:54:05,563 [Thread-1] DEBUG o.x.shutdown - > Stopping Database Connection Pool... > 2014-09-23 13:54:05,735 [Thread-1] DEBUG o.x.shutdown - > Database Connection Pool has been stopped > 2014-09-23 13:54:10,513 [Thread-1] DEBUG o.x.shutdown - > Stopping component > [org.xwiki.localization.wiki.internal.DocumentTranslationBundleFactory]… > 2014-09-23 13:54:10,513 [Thread-1] DEBUG o.x.shutdown - > Component > [org.xwiki.localization.wiki.internal.DocumentTranslationBundleFactory] has > been stopped > … > 2014-09-23 13:54:10,514 [Thread-1] DEBUG o.x.shutdown - > Stopping component [org.xwiki.search.solr.internal.DefaultSolrIndexer]... > 2014-09-23 13:54:10,514 [Thread-1] DEBUG o.x.shutdown - > Component [org.xwiki.search.solr.internal.DefaultSolrIndexer] has been stopped > … > 2014-09-23 13:54:10,539 [Thread-1] INFO o.x.shutdown - > XWiki shutdown has been completed. > > As you can see the problem is that the DB is stopped first. So any code > accessing the DB will get an error once the connection pool is stopped. This > is why we get a lot stack traces when you ctrl-c XWiki quickly after it > starts (i.e. when the init is not finished or when SOLR is still indexing). > You can also get stack traces if a watchlist is being sent or some scheduler > job is executing for example. > > There are 2 ways to fix this: > - solution 1: all code that accesses the DB could check if an XWiki shutdown > is in progress and don’t generate stack traces if this is the case > - solution 2: stop the DB as the last thing, after everything else has stopped > > Obviously solution 2 is much better. > > I’ve started implementing it by doing this: > - Remove the current HibernateShutdownEventListener since this is executed > first during shutdown, before component disposal > - Instead have XWikiHibernateStore implement Disposable and move the content > of HibernateShutdownEventListener in that method > > This works already better but it’s not enough since ECM.dispose() works out > the component dependencies but this works only for explicit dependencies and > doesn’t work if a component uses the ComponentManager to dynamically find > implementations (as this is the case for example for DefaultSolrIndexer). > > Thus in order to help the component disposal process, I propose to introduce > a new annotation: @DisposePriority(int). > > Note that an alternative would be to introduce a new Disposable interface > with a new getPriority() method in it (we cannot modify the current > Disposable since that would break backward compat).
It's always hard to know what priority to put exactly so this is last resort solution for me. A few other alternatives: 1) stop the DB after disposing components (I would not vote for it I think but it should work for this use case) 2) introduce something like a @ComponentDependency annotation to let component declare indirect dependencies (ECM#dispose would simply add @ComponentDependency annotations to its current dependencies based ordering) and: 2.1) even when a component does not directly use XWikiStoreInterface (pretty much all of them are using XWiki methods and don't even know about it officially) we could still ask them to declare something like @ComponentDependency(XWikiStoreInterface.class) to indicate that they want to be disposed after any component of this role. 2.2) make XWiki instance a component instead of storing it in the servlet context and inject it instead of accessing it through XWikiContext (XWiki itself would inject the component it want). XWiki itself would declare a @ComponentDependency(XWikiStoreInterface.class). 2.3) move all storage related methods from XWiki (saveDocument, getDocument, etc) to another component (and remove XWikiContext parameter to all these methods) which would be injected by components directly instead of searching for the XWikiContext (that's how new model will work but we can have another one before that still expose olcore APIs like XWikiDocument). Then this component would take care of declaring the @ComponentDependency(XWikiStoreInterface.class) (it's not really possible to directly inject the right XWikiStoreInterface since it's configuration based) > > The idea is then to use this information in ECM.dispose() to first sort all > components based on this and then only to order them with their dependencies. > > WDYT? > > Thanks > -Vincent > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs I prefer any of the 2.x over priority based ordering and I think the nicest for components is 2.3. -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
