[
https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744231#comment-16744231
]
Marshall Schor commented on UIMA-5935:
--------------------------------------
hmmm - I don't think this is the cause.
We definitely don't want to clear this cache - as it is global for the whole
JVM + classloader context, which might have many pipelines running, not related
to a particular PEAR.
Can you say how you arrange to call the "destroy" method of the resource
manager used for the PEAR? The framework (I believe) never calls this method,
expecting those users who want to, to call it themselves.
Perhaps the "bug" is that when the "outer" resource manager's destroy method is
called, the framework should add code to call destroy on any PEAR resource
managers for which it is the parent.?
> Destroy the ResourceManager on destroy of a pear
> -------------------------------------------------
>
> Key: UIMA-5935
> URL: https://issues.apache.org/jira/browse/UIMA-5935
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.10.3SDK
> Reporter: Philipp Butz
> Assignee: Marshall Schor
> Priority: Major
> Fix For: 3.0.2SDK, 2.10.4SDK
>
> Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff
>
>
> This bug is related to bug UIMA-5799 . The bug seems not completely fixed,
> since the files are still being accessed after trying to delete them. This
> behavior can be shown by the tool 'lsof' (see screenshot). There seems still
> access to the resources of a pear on the file system, which denies the
> complete deletion on the file system after uninstalling it (they are marked
> as deleted but are not actually removed).
>
> Potential cause:
> The class PearAnalysisEngineWrapper creates and caches resource managers. The
> elements in that Cache (Java map) are never explicitly removed, not even in
> the destroy method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
