[jira] [Comment Edited] (UIMA-6155) uimaFIT JCasIterable.iterator() destroys ResourceManager

["Richard Eckart de Castilho (Jira)" <de...@uima.apache.org>]

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

Richard Eckart de Castilho edited comment on UIMA-6155 at 1/29/20 11:14 AM:
----------------------------------------------------------------------------

Ok, so here again an analysis of this bug.

* JCasIterable.iterator() internally creates/obtains a resource manager
* then JCasIterable.iterator() internally creates an iterato, passes the resource manager on to it and then returns it
* Directly after returning the the iterator, JCasIterable.iterator() destroys the resource manager

This is obviously wrong but probably doesn't surface as an issue unless one uses a ResourceManagerFactory which returns the same resource manager again and again.

So we kind of have two issues here: 

1) JCasIterable should do sane things if no "singleton" resource manager is injected via ResourceManagerFactory
2) there needs to be some sane way of working with a shared resource manager

For 1) Simply not destroying the resource manager in JCasIterable.iterator() doesn't fix the issue because JCasIterator itself won't destroy a resource manager it has not created itself. So the fix for this aspect involves not letting JCasIterable.iterator() create the resource manager in the first place and leave its lifecycle entirely to JCasIterator.

For 2) Add additional signature to JCasIterable and friends which allow passing in an externally created resource manager - this one is then not destroyed. Returning a singleton resource manager from ResourceManagerFactory is a *terribly bad idea* (because it gets destroyed all the time) - but if somebody were to do this, then it should be passed explicitly to to JCasIterable and friends to avoid it getting destroyed.



was (Author: rec):
Ok, so here again an analysis of this bug.

* JCasIterable.iterator() internally creates/obtains a resource manager
* then JCasIterable.iterator() internally creates an iterato, passes the resource manager on to it and then returns it
* Directly after returning the the iterator, JCasIterable.iterator() destroys the resource manager

This is obviously wrong but probably doesn't surface as an issue unless one uses a ResourceManagerFactory which returns the same resource manager again and again.

So we kind of have two issues here: 

1) JCasIterable should do sane things if no "singleton" resource manager is injected via ResourceManagerFactory
2) there needs to be some sane way of working with a shared resource manager

For 1) Simply not destroying the resource manager in JCasIterable.iterator() doesn't fix the issue because JCasIterator itself won't destroy a resource manager it has not created itself. So the fix for this aspect involves not letting JCasIterable.iterator() create the resource manager in the first place and leave its lifecycle entirely to JCasIterator.

For 2) ... watch this space ...


> uimaFIT JCasIterable.iterator() destroys ResourceManager
> --------------------------------------------------------
>
>                 Key: UIMA-6155
>                 URL: https://issues.apache.org/jira/browse/UIMA-6155
>             Project: UIMA
>          Issue Type: Bug
>          Components: uimaFIT
>    Affects Versions: 3.0.0uimaFIT
>            Reporter: Peter Klügl
>            Assignee: Richard Eckart de Castilho
>            Priority: Major
>
> The method JCasIterable.iterator() destroys the ResourceManager used to create the analysis engines, which can cause problems when the destroy is delegated to the destroy methods of the components and resources. These can be invalid during the pipeline processing by the iterator.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)