[
https://issues.apache.org/jira/browse/ACCUMULO-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859073#comment-13859073
]
Josh Elser commented on ACCUMULO-2115:
--------------------------------------
I imagine that this would continue to bite us through all releases, no? I can't
imagine commons-vfs having anything magical that would "fix" this kind of issue
for us in 1.5.0.
Tying a scan back to the Iterator(s) that might be loaded from a jar that was
replaced would likely get rather messy. It's probably possible to inspect the
Scan "stack" (and table configuration?) to determine if a jar is in use before
replacing it in the classloader. Do you have any thoughts about how to
implement this?
> class loader issues when replacing jar that is actively being used
> ------------------------------------------------------------------
>
> Key: ACCUMULO-2115
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2115
> Project: Accumulo
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.4.4, 1.5.0
> Reporter: Ivan Bella
> Priority: Minor
> Labels: class_loader
>
> When replacing a jar in the lib/ext directory while active iterators are
> using the previous jar will result is many class loader issues. New
> iterators started up may also show class loader issues. This will probably
> persist until the previously active iterators complete and release the
> previous ClassLoader instance, but that is merely a guess.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
