uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-5156) ResourceManager automatic destory
Date Mon, 24 Oct 2016 15:17:58 GMT

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

Marshall Schor commented on UIMA-5156:

It was pointed out that no existing code calls destroy() on RM, so backwards compatibility
might not be an issue.

It does however, seem that implementing any kind of automatic destroy() call has the potential
to break user code, for the case
where the user used the "automatic" creation of an RM, followed by then getting that RM and
passing it (in additionalParameters) to other produceResource calls.

I can't figure out a way to detect if this is happening.  The test would need to be something
like: is this Resource manager "held" by some other Java object?  

Putting in this would "break" those kinds of applications.  I wonder if the benefit of this
is worth the troubles it may cause to users?

Not putting this in would leave the requirement of calling destroy() to those users for whom
it was important; and they would have the extra burden of calling it in the case where the
UIMA Framework "automatically" created the RM.

> ResourceManager automatic destory
> ---------------------------------
>                 Key: UIMA-5156
>                 URL: https://issues.apache.org/jira/browse/UIMA-5156
>             Project: UIMA
>          Issue Type: Improvement
>            Reporter: Marshall Schor
>            Priority: Minor
> UIMA-2977 adds a destory() method to the ResourceManager (RM), that forwards this call
to external resources managed by that RM.
> The destroy() method was not called by the framework, because in general the RM may be
shared by the user (or framework) among multiple pipelines.
> This Jira is to enable RMs created by the framework to call destroy() internally at the
appropriate time.
> This assumes that the right time can be figured out for the various cases.
> These include: MultiprocessingAnalysisEngine_impl, and fixing other associated frameworks
which may use a pattern where they 
> * let the framework create a RM, but then 
> * use that in other contexts.  

This message was sent by Atlassian JIRA

View raw message