You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2013/07/14 21:44:48 UTC

[jira] [Commented] (UIMA-2977) destroy method of shared resources never called

    [ https://issues.apache.org/jira/browse/UIMA-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708106#comment-13708106 ] 

Marshall Schor commented on UIMA-2977:
--------------------------------------

Analysis Engine do not automatically have their destroy methods called for the event "when the component is disposed of"; UIMA doesn't have a formal concept of this event.  For instance, one could do the following with the UIMA Application APIs:  Read in a descriptor, create an analysis engine, send it some CASes and do something with the results, and then terminate.  In this scenario, no "destroy" would be called; it's up to the surrounding application code to call (or not) the destroy() method.

When the destroy method is called on an annotator, the framework does takes care of propagating this to its delegates.  However it doesn't propagate to any shared resources that might have been loaded and set up; because they're shared, they conceivably could still be in use by other annotators which were not destroyed.

If some piece of user application code had a reference to a resource (not an annotator, but an External Resource), then, that code *could* call the destroy method on that resource.  

In order to implement a fix for this Jira, one would need to define another layer of lifecycle management for UIMA, I think, in order to be able to reliably determine when a (shared) resource was no longer needed.  A counter-example use case for doing, for instance, a reference-counting scheme for determining when to call destroy that relied on determining when *all* the annotators that had linked to it had been destroyed, could be:

1) The top application sets up some UIMA pipelines to act as services.  Some of these load (via external resources), some large, slow-to-load resources, and share them.

2) The top application needs to remain "responsive", but is able to shut down some of its loaded pipelines, in response to changing user requests (load).  If at some point, it shutdown all of its pipelines, and then got some more user requests, it might want to quickly startup some pipelines, but avoid the load time of (some of) the external resources - so it might *choose* to keep these loaded.
                
> destroy method of shared resources never called
> -----------------------------------------------
>
>                 Key: UIMA-2977
>                 URL: https://issues.apache.org/jira/browse/UIMA-2977
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>            Reporter: Richard Eckart de Castilho
>
> Apparently the ResourceManager and the resources created by the manager do not participate in the usual component life cycle. On other components, such as analysis engines or readers, the destroy() method is called when the component is disposed of. External resources never get notified when they are no longer needed. At least any resources derived from Resource (e.g. DataResource and ParametrizedDataResource) should be notified. The SharedResourceObject interface does not define any such life cycle callback.
> As a side-note: An alternative to the rather heavy-weight Resource interface of UIMA maybe be small life cycle interfaces such as the Spring InitializingBean and DisposableBean interfaces, or Java annotations marking initialization and destruction methods (e.g. @PostConstruct and @PreDestroy).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira