[
https://issues.apache.org/jira/browse/ACCUMULO-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14286846#comment-14286846
]
Josh Elser commented on ACCUMULO-1292:
--------------------------------------
Giving it a quick look (not nearly in the depth/context necessary):
Why the need to use a new thread to rebuild the classloader in either patch?
It's possible that I'm not understanding the problem entirely, though.
If you have multiple callers coming in that want to reload the classloader, you
only want one to do that reload, and then have the other callers use the result
from the single caller which actually updated the classloader. All of the
callers try to race to reinitialize the classloader, one wins and updates it,
while the others wait for it to finish. In other words, the ReadWriteLock and
marking the VFSClassLoader as volatile or wrapping it in an AtomicReference
seems to me to provide all the concurrency control that you need. Did I
misinterpret the problem?
> Tablet constructor can hang on vfs classloader, preventing tablets from
> loading
> -------------------------------------------------------------------------------
>
> Key: ACCUMULO-1292
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1292
> Project: Accumulo
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.5.0, 1.6.0, 1.6.1
> Reporter: John Vines
> Assignee: Eric Newton
> Fix For: 1.7.0, 1.6.3
>
> Attachments: ACCUMULO-1292-using-locks.patch, ACCUMULO-1292.patch
>
>
> Taken from TODO from r1424106 regarding ACCUMULO-867. This is something that
> we should at least look into more before 1.5 is released.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
