accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Marion (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (ACCUMULO-1292) Tablet constructor can hang on vfs classloader, preventing tablets from loading
Date Thu, 22 Jan 2015 18:48:34 GMT

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

Mime
View raw message