[jira] [Resolved] (STANBOL-1416) FST linking engine activation issue

["Rupert Westenthaler (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STANBOL-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rupert Westenthaler resolved STANBOL-1416.
------------------------------------------
    Resolution: Fixed

fixed with http://svn.apache.org/r1674012 in 0.12; merged with http://svn.apache.org/r1674016 to trunk;

> FST linking engine activation issue
> -----------------------------------
>
>                 Key: STANBOL-1416
>                 URL: https://issues.apache.org/jira/browse/STANBOL-1416
>             Project: Stanbol
>          Issue Type: Bug
>          Components: Enhancement Engines
>            Reporter: Rupert Westenthaler
>            Assignee: Rupert Westenthaler
>            Priority: Minor
>
> During the {{activate()}} the FST Linking Engine Component opens an OSGI ServiceTracker for the configured SolrCore (used for FST linking).
> However this activation might end in a RuntimeException in some cases (e.g. if the core is not valid or in the listing below the directory for the FST models is not existent and can not be created.
> {code}
> Unable to create Directory forstoring the FST files at location '/<path>/data/fst'.) java.lang.IllegalStateException: Unable to create Directory forstoring the FST files at location '/<path>/data/fst'.
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent.getFstDirectory(FstLinkingEngineComponent.java:857)
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent.updateEngineRegistration(FstLinkingEngineComponent.java:752)
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent$1.addingService(FstLinkingEngineComponent.java:686)
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent$1.addingService(FstLinkingEngineComponent.java:660)
> 	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)
> 	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864)
> 	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> 	at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> 	at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:317)
> 	at org.apache.stanbol.commons.solr.RegisteredSolrServerTracker.open(RegisteredSolrServerTracker.java:114)
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent.applyConfig(FstLinkingEngineComponent.java:694)
> 	at org.apache.stanbol.enhancer.engines.lucenefstlinking.FstLinkingEngineComponent.activate(FstLinkingEngineComponent.java:361)
> [..]
> {code}
> Important to note is that the a SolrCore that is already registered as Service is directly added to the ServiceTracker within the thread context of the {{activate()}} call to the FstLinkingEngineComponent. So any Exception during this registration (that also triggers the configuration of the FstLinkingEngine) can still fail the activation of the FstLinkingEngineComponent.
> If this happens the component is in an invalid state:
> * OSGI lists the component as 'unsatisfied'
> * The ServiceTracker is still open (and active)
> So what can happen is that the tracked SolrCore is updated. In this case the 'unsatisfied' component processes the event and - if successful - registers a FstLinkingEngine as OSGI service.
> However even so the component itself will still be in the 'unsatisfied'. So if their is an update to the FstLinkingEngineComponent configuration OSGI will NOT call {{deactivate()}}.
> Because of that the FstLinkingEngine service registered by the unsatisfied component will never get unregistered and one can end up with multiple Services registered for the same component configuration. For the FstLinkingEngine this means that one will have two EnhancementEngine Instances for the same configuration.
> Most likely they will have the same name. In such cases the Enhancer will always use the instance with the higher {{service.ranking}}. If those are the same - expected in such a scenario - it will select the service with the lower service id. As OSGI increases the service id for every service that get registered the older service instance will get use by the enhancer.
> This means that the service registered by the unsatisfied Component instance will get used as it does have the lower service id.
> To solve this situation it is necessary to stop/start the FST linking bundle. This is the only possibility to cause the removal of service as OSGI keeps track what bundles do register Services.
> To fix this issue it is necessary to catch any Exception thrown during the {{ServiceTracker.open()}} call. Even in case of an Exception the tracker keeps listening to further service event. So a later event might trigger the correct initialization of the FstLinkingEngine. Catching the Exception ensures that the FstLinkingEngineComponent is in the 'active' state and OSGI calls {{deactivate()}} to unregister any FstLinkingEngine service and close the ServiceTracker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)