accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3954) TabletServer advertises existence before acquiring its lock
Date Wed, 12 Aug 2015 12:07:46 GMT


Keith Turner commented on ACCUMULO-3954:

I looked at the code, it does seems to be doing the right thing.  It calls  {{getChildren()}}
for each child at [ line 119|].
 That code is duplicating {{ZooLock.getLockData()}} and should probably just call  {{ZooLock.getLockData()}}.

bq.  If we get the lock before advertising our existence

The lock node should be the advertisement.   The code in {{InstanceOperationsImpl.getTabletServers()}}
seems to be reading the lock node.  I looked around in the tserver code for synchronization
issues where the tserver has created the lock node, but has not updated its internal memory
structures to reflect that.   I was looking in master.  The synchronziation seems ok.  In
{{announceExistence()}} it calls {{ZooLock.tryLock()}} which is synchronized and creates the
lock node.  This should be mutually exclusive with the call to {{tabletServerLock.wasLockAcquired()}}
in {{TabletServer.ThriftClientHandler.checkPermission()}}

One possibility is that something like the following is happening :

 1. Process A gets a list of tservers
 2. Tserver 1 is restarted on same port
 3. Process A contacts Tserver 1 while its starting up

> TabletServer advertises existence before acquiring its lock
> -----------------------------------------------------------
>                 Key: ACCUMULO-3954
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>    Affects Versions: 1.6.3, 1.7.0
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Trivial
>             Fix For: 1.8.0
> Noticed this error today on the monitor after restarting Accumulo:
> {noformat}
> 2015-08-06 16:57:10,788 [tserver.TabletServer] WARN : tserver:hostname Got getScans message
from master before lock acquired, ignoring...
> 2015-08-06 16:57:10,791 [tserver.TabletServer$ThriftClientHandler] ERROR: tserver:jelser-phoenix-1.openstacklocal
Lock not acquired
> java.lang.RuntimeException: Lock not acquired
>         at org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.checkPermission(
>         at org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.getActiveScans(
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(
>         at org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(
>         at com.sun.proxy.$Proxy21.getActiveScans(Unknown Source)
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$getActiveScans.getResult(
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$getActiveScans.getResult(
>         at org.apache.thrift.ProcessFunction.process(
>         at org.apache.thrift.TBaseProcessor.process(
>         at org.apache.accumulo.server.rpc.TimedProcessor.process(
>         at org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(
>         at org.apache.accumulo.server.rpc.CustomNonBlockingServer$
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
>         at
> {noformat}
> I don't think this should be bubbling up to the monitor as an error. I believe it is
an entirely normal race condition that can happen. If the tabletserver is not ready to accept
an RPC, it can log a message at debug. The error condition would be a tabletserver never acquiring
its lock (and thus should be handled elsewhere).

This message was sent by Atlassian JIRA

View raw message