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