You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2017/01/24 22:45:26 UTC

[jira] [Commented] (HBASE-17487) Log error when pushing pipeline to snapshot fails twice

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

stack commented on HBASE-17487:
-------------------------------


bq. When operator faces problem in cluster, reading log is vital part of troubleshooting.

You make no sense. What we are talking about here is a silent log of an ERROR. You imply that the operator will be randomly reading logs looking for 'errors'. Operators don't do that. Nor should the expectation be that they should. If there is a problem here, handle it or abort. Flip from WARN to ERROR is close to useless.

bq. I was reviewing HBASE-17081 and came to paying attention to the code mentioned in this JIRA.

So, just speculation.

Issues like this waste attention cycles that could be better focused on higher priority items. Three distinct devs other than yourself have not been pulled into this issue that I'm about to mark trivial. Do you have nothing more substantial to work on?

> Log error when pushing pipeline to snapshot fails twice
> -------------------------------------------------------
>
>                 Key: HBASE-17487
>                 URL: https://issues.apache.org/jira/browse/HBASE-17487
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Ted Yu
>            Assignee: Ted Yu
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: 17487.v2.txt, 17487.v3.txt
>
>
> In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 iterations of pipeline.swap() call after which an empty ImmutableSegment is used as snapshot.
> However, there should be at most two iterations in pushPipelineToSnapshot() since during the second iteration there is no concurrent write to memstore.
> We should log error in the 3rd iteration to signify that this scenario should never happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)