[
https://issues.apache.org/jira/browse/HBASE-28809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878843#comment-17878843
]
guluo commented on HBASE-28809:
-------------------------------
Makes sense, there is indeed no need to do more processing based on your reply.
Thank you very much for your detailed reply.
> Client always send flush requests twice when flush procedure is disabled
> ------------------------------------------------------------------------
>
> Key: HBASE-28809
> URL: https://issues.apache.org/jira/browse/HBASE-28809
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Affects Versions: 2.6.0, 4.0.0-alpha-1
> Environment: hbase 2.6.0
> centos7
> Reporter: guluo
> Assignee: guluo
> Priority: Major
>
> When hbase disable flush procedure at server side, whether flush procedure is
> diabled or not at clien side, client always sends flush requests twice.
> In current hbase, There are four situations about flush request:
> 1. Both server and client enables flush Procedure, Client only sends a flush
> request by flush procedure.
> 2. Server disabled flush procedure and client enables flush procedurce,
> Client sends a flush request by flush procedure, after failure ,it will sends
> a flush request by old flush implementation
> 3. Server enables flush procedure and client disables flush procedure, Client
> only send a flush request by flush procedure
> 4. Both server and client disables flush Procedure, Client alwalys sends a
> flush request by flush procedure at first, after failure ,it will sends a
> flush request by old flush implementation
>
> The situation 1/2 is no problem.
> For situation 3, I think client should only send a flush request by old flush
> implementation instead of flush procedure
> For situation 4, I think client should only send a flush request by old flush
> implementation, instead of first using flush procedure, and then switching to
> old flush implementation after failing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
