[
https://issues.apache.org/jira/browse/ACCUMULO-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Marion updated ACCUMULO-1292:
----------------------------------
Comment: was deleted
(was: bq. What would happen with the VFS classloader if a filesystem change
happened (Jar was replaced), refresh on the classloader is started but takes a
long time, class load is requested for a class that was from the replaced jar?
Is that safe – it would continue to load the old version of the class? Would
requests before the classloader is updated fail?
The classloader should provide the old version of the jar until the new
classloader is constructed. This behavior should be the same as the previous
implementation of the classloader. It would fail if your application depended
on the new jar being available at a certain time. I don't think we have ever
had a guarantee on some time constraint across all of the tservers. It's
eventually consistent within, most likely, 2 times the refresh interval. The
default interval is 30 seconds, but appears to be overridden in
AccumuloVFSClassLoader to 1 second (with a TODO to make configurable). Having
said that, if the thread is hung on I/O to HDFS or some other service that VFS
supports (http, ftp, etc.) for retrieving jars, we can't provide any guarantee.
bq. Wouldn't Executors.newSingleThreadExecutor() be more concise? Is your
keepAliveTime actually doing to do anything with a coreSize of 1?
I want to ensure that 1 thread is running and that there is a max of 2
objects in the queue. I don't believe that with
Executors.newSingleThreadExecutor() that you can change or control the size of
the queue. My keepAliveTime should do nothing, but I don't think there is a
constructor variant that does not require the information.
bq. Need to make sure that the async refreshing thread is a daemon or provide a
way to stop the thread.
Good point, we should make it a daemon, maybe provide a ThreadFactory to the
ThreadPoolExecutor.
bq. executor.shutdown();
Good point.)
> 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-atomic-update.patch,
> 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)