[ 
https://issues.apache.org/jira/browse/PHOENIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006907#comment-16006907
 ] 

James Taylor commented on PHOENIX-3811:
---------------------------------------

Yes, [~mvanwely] - the retries are at the HBase level and will still occur as 
usual. Only after these fail would HBase throw an exception which would 
subsequently make it's way back to the client.

It's important that the client deal with the failure correctly or your index 
would become corrupted. Here's what you'd need to do:
* catch CommitException from your client code and use 
commitException.getServerTimestamp() to retrieve the server timestamp.
* process failed batches from earliest to latest timestamp.
* set the RETRY_AT connection property to the timestamp before retrying the 
batch

If you don't set the REPLAY_AT property and earlier batches are processed 
before later batches, you run the risk of overwriting a row with an earlier 
value. Also, if you process the later batch first, then when the earlier batch 
comes along, the already committed later batch won't be considered leading to 
an invalid index.

> Do not disable index on write failure by default
> ------------------------------------------------
>
>                 Key: PHOENIX-3811
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3811
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>             Fix For: 4.11.0
>
>         Attachments: PHOENIX-3811_v1.patch, PHOENIX-3811_v2.patch, 
> PHOENIX-3811_v3.patch, PHOENIX-3811-wip1.patch, PHOENIX-3811-wip2.patch, 
> PHOENIX-3811-wip3.patch, PHOENIX-3811-wip4.patch, PHOENIX-3811-wip5.patch, 
> PHOENIX-3811-wip7.patch
>
>
> We should provide a way to configure the system so that the server takes no 
> specific action when an index write fails. Since we always throw the write 
> failure back to the client, the client can often deal with failures more 
> easily than the server since they have the batch of mutations in memory. 
> Often times, allowing access to an index that may be one batch behind the 
> data table is better than disabling it given the negative performance that 
> will occur while the index cannot be written to.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to