accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2964) Unexpected ThriftSecurityException from BatchScanner
Date Fri, 11 Jul 2014 19:45:05 GMT


Josh Elser commented on ACCUMULO-2964:

Digging into this more makes me think that there are two separate issues here. There is the
inexplicable network/thrift error which I don't yet have a grasp on, and there is the issue
with the batchwriter repeatedly failing. I've opened ACCUMULO-2990 for the latter and will
reduce the priority on this issue again until I can get a better understanding of what's happening.

> Unexpected ThriftSecurityException from BatchScanner
> ----------------------------------------------------
>                 Key: ACCUMULO-2964
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client, tserver
>            Reporter: Josh Elser
>            Priority: Critical
>             Fix For: 1.6.1, 1.7.0
> This is something I've only seen a handful of times when writing/running tests that stop
and restart tservers. After the tserver is restarted, there is a thread (typically running
in the master) which is trying to read a table. As such, the thread will continue to poll
until the tserver comes up.
> Very infrequently, the client gets a {{ThriftSecurityException}} with a code of {{DEFAULT_SECURITY_ERROR}}
and a message of {{Unknown security exception}}. There is no additional information in the
client log (from the thrift call inside the batchscanner), and the tserver contains no error
messages at all.
> The error that the client saw.
> {noformat}
> 2014-07-01 04:18:18,971 [impl.TabletServerBatchReaderIterator] DEBUG: Server : host:58090
msg : null
> ThriftSecurityException(user:!SYSTEM, code:null)
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$startMultiScan_result$
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$startMultiScan_result$
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$
>         at org.apache.thrift.TServiceClient.receiveBase(
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Client.recv_startMultiScan(
>         at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Client.startMultiScan(
>         at org.apache.accumulo.core.client.impl.TabletServerBatchReaderIterator.doLookup(
>         at org.apache.accumulo.core.client.impl.TabletServerBatchReaderIterator.doLookup(
>         at org.apache.accumulo.core.metadata.MetadataLocationObtainer.lookupTablets(
>         at org.apache.accumulo.core.client.impl.TabletLocatorImpl.processInvalidated(
>         at org.apache.accumulo.core.client.impl.TabletLocatorImpl.binRanges(
>         at org.apache.accumulo.core.client.impl.TabletLocatorImpl.processInvalidated(
>         at org.apache.accumulo.core.client.impl.TabletLocatorImpl._locateTablet(
>         at org.apache.accumulo.core.client.impl.TabletLocatorImpl.locateTablet(
>         at org.apache.accumulo.core.client.impl.ThriftScanner.scan(
>         at org.apache.accumulo.core.client.impl.ScannerIterator$
>         at org.apache.accumulo.core.client.impl.ScannerIterator.hasNext(
>         at org.apache.accumulo.master.replication.DistributedWorkQueueWorkAssigner.createWork(
>         at org.apache.accumulo.master.replication.DistributedWorkQueueWorkAssigner.assignWork(
>         at
> {noformat}
> The interesting part is that when the client saw this message, the new TabletServer was
already started, and the old tabletserver appears to have been dead for 20s. So, the client
in the master had been polling for 20s getting a ConnectException (connection refused) which
is expected. I don't know why we got this exception after a length of time.
> The infrequency in which I see this makes me wonder if the random ports in the new tabletserver
are somehow re-grabbing the old tserver's thrift client service port and something is unexpectedly
being interpreted as this ThriftSecurityException? That's the only thing that seems remotely
possible to me. 

This message was sent by Atlassian JIRA

View raw message