Write an iterator to compute partial sums. Make sure the iterator does not
return a key outside if the range to which it was seeked. (You don't have
to modify the keys you return; just sum the keys below the first one for
each key prefix into the first one.)
Collect the partial sums at the client
Jeff,
Take a look at the master logs for where the WAL was sorted to the
/accumulo/recovery/...
directory. Then look to see if those WALs are still around and contain
content.
Where is this this EOF exception, on a tserver?
Is the master log complaining about anything?
Mike
On Mon, Oct 17, 20
On Tue, Oct 18, 2016 at 6:32 AM, Michael Wall wrote:
> Take a look at the master logs for where the WAL was sorted to the
> /accumulo/recovery/...
> directory. Then look to see if those WALs are still around and contain
> content.
>
Checked one of them, yes it is around with content.
Where is
Mike,
For one of the WALs I backed up the recovery directory and that
initiated a new recovery attempt as indicated in the tserver debug log...
Then the exception was thrown:
Unable to find recovery files for extent xx logentry x
hdfs://path/to/wal/
Any ideas? I figure we can z
Andrew,
That is what I was going to suggest you try. Where is that "Unable to find
recovery files for extent" log? Anyway we can see some actual logs?
Are all the WALs there? Do you find any of the WAL deleted by GC in the gc
logs? Do you find any duplicates WALs in the HDFS trash?
On Tue, O
+1 to what Dylan said.
The naive approach would be to run a scan from [rowID:,rowID;), parse
out the otherID and count them. The iterator approach Dylan suggested
would push this work to the TabletServer which would likely result in a
much more efficient computation.
Dylan Hutchison wrote:
Mike,
So backing up and then later deleting the recovery directories a few
times did the trick. It seemed that removing the initial bad one caused
the others to go through for the most part...
I believe all the WAL files were there. I'll look for the WAL deleted in
the GC logs and see if the
Do you have the full exception for the "Expected protocol id.." error?
That looks like it might be incorrect usage of Thrift on our part..
Andrew Hulbert wrote:
Mike,
So backing up and then later deleting the recovery directories a few
times did the trick. It seemed that removing the initial b
Note that the error is more like this:
Expected protocol id ff82 but got 35 (0!;38\\;82,:9997,
)
On 10/18/2016 10:28 AM, Andrew Hulbert wrote:
Mike,
So backing up and then later deleting the recovery directories a few
times did the trick. It seemed that removing the initial bad one
I'll try to dig up the full error from the tserver
On 10/18/2016 10:30 AM, Josh Elser wrote:
Do you have the full exception for the "Expected protocol id.." error?
That looks like it might be incorrect usage of Thrift on our part..
Andrew Hulbert wrote:
Mike,
So backing up and then later de
Or, if it's more convenient, this is the issue I was thinking of:
https://issues.apache.org/jira/browse/ACCUMULO-4065
Andrew Hulbert wrote:
I'll try to dig up the full error from the tserver
On 10/18/2016 10:30 AM, Josh Elser wrote:
Do you have the full exception for the "Expected protocol i
Yes, it looks similar.
Esp these parts:
2015-11-19 22:43:05,998 [impl.TabletServerBatchReaderIterator] DEBUG:
org.apache.thrift.protocol.TProtocolException: Expected protocol id ff82
but got 19
java.io.IOException: org.apache.thrift.protocol.TProtocolException: Expected
protocol id ff
I think it is attempting to do migrations at the moment FYI
On 10/18/2016 10:40 AM, Andrew Hulbert wrote:
Yes, it looks similar.
Esp these parts:
2015-11-19 22:43:05,998 [impl.TabletServerBatchReaderIterator] DEBUG:
org.apache.thrift.protocol.TProtocolException: Expected protocol id ff8
13 matches
Mail list logo
