[ 
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)

Reply via email to