[
https://issues.apache.org/jira/browse/HBASE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-831:
------------------------
Attachment: 831-v2-shortertimeouts.patch
I think that the pause should be shorter still. Rather than 8 seconds, it
should be 2 seconds. Attached file changes the pause to 2 seconds and removes
the 64 off the end of RETRY_BACKOFF.
At 2 seconds all is 'snappier' -- creating, disablng, etc. -- and after ten
retries we're at about 2 minutes which is long-enough in my opinion and is <
TaskTracker timeout of ten minutes so we'll see error in MR logs rather than
child killed messages.
At 8 seconds, with RETRY_BACKOFF as it was, we're waiting > 17 minutes (if I
did my math right).
This patch passes all unit tests. Also tried it in a big MR job. More logging
if client DEBUG is enabled but at least now you have a better clue whats going
on.
> committing BatchUpdate with no row should complain
> --------------------------------------------------
>
> Key: HBASE-831
> URL: https://issues.apache.org/jira/browse/HBASE-831
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.2.0
> Reporter: Michael Bieniosek
> Assignee: Andrew Purtell
> Priority: Minor
> Fix For: 0.2.1, 0.3.0
>
> Attachments: 831-v2-shortertimeouts.patch, 831.patch
>
>
> Running this code:
> BatchUpdate update = new BatchUpdate();
> update.put(key, value);
> table.commit(update);
> Down in getRegionServer, this triggers an NPE because the row is null (which
> I saw because I was running in a debugger); this NPE gets retried somewhere
> in the bowels of IPC. Instead, we should either remove the zero-arg
> BatchUpdate constructor, or have table.commit throw a runtimeexception if the
> row is null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
