[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Labels: patch (was: newbie patch) > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: patch > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15866-branch-1.patch, HBASE-15866.patch, > HBASE-15866.patch, HBASE-15866.patch, HBASE-15866.patch, HBASE-15866.patch, > read-write-rpc-timeouts.patch, read-write-rpc.v1.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Attachment: HBASE-15866.patch Contains changes on the latest master branch > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, HBASE-15866.patch, HBASE-15866.patch, > read-write-rpc-timeouts.patch, read-write-rpc.v1.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Attachment: (was: read-write-rpc-timeouts-edited.v2.patch) > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, read-write-rpc-timeouts.patch, > read-write-rpc.v1.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Attachment: read-write-rpc.v1.patch > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, read-write-rpc-timeouts.patch, > read-write-rpc.v1.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Release Note: Fixed broken unit test and added unit tests for TestHCM#testWriteRpcTimeout and TestHCM#testReadRpcTimeout, along with necessary changes to make that work. This is the patch labelled "read-write-rpc-timeouts-edited.v2.patch" Status: Patch Available (was: In Progress) > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, > read-write-rpc-timeouts-edited.v2.patch, read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Attachment: read-write-rpc-timeouts-edited.v2.patch > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, > read-write-rpc-timeouts-edited.v2.patch, read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15866 started by Vivek Koppuru. - > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15638) Shade protobuf
[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389898#comment-15389898
]
Vivek Koppuru edited comment on HBASE-15638 at 7/22/16 5:51 PM:
Sorry about the comments in activity, I accidentally put my work into the wrong
JIRA.
was (Author: vivek.kopp...@gmail.com):
Sorry about the comments, I accidentally put my work into the wrong JIRA.
> Shade protobuf
> --
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 15638v2.patch, HBASE-15638.master.001.patch,
> HBASE-15638.master.002.patch, HBASE-15638.master.003.patch,
> HBASE-15638.master.003.patch, as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Labels: newbie patch (was: ) Affects Version/s: 2.0.0 Status: Patch Available (was: In Progress) I split the rpcTimeout in HTable.java into readRpcTimeout and writeRpcTimeout, which can also go back to the rpcTimeout value that would be set if the user did not configure those values. Then throughout HTable, whenever making an rpcCallerFactory call, I would pass the appropriate read/write rpc timeout. I also made a change to the AsyncProcess class constructor to allow for the use of writeRpcTimeout, which then I made appropriate changes to BufferedMutatorImpl.java, ConnectionImplementation.java, HTableMultiplexer.java, and TestAsyncProcess.java to account for this parameter change and passed in the appropriate rpc timeout. Finally, I made sure I included constants in HConstants.java to retrieve the value of "hbase.rpc.read.timeout" and "hbase.rpc.write.timeout" and to also allow for fallback to "hbase.rpc.timeout" and the default rpc timeout if none of those are set. > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15638) Shade protobuf
[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389898#comment-15389898
]
Vivek Koppuru commented on HBASE-15638:
---
Sorry about the comments, I accidentally put my work into the wrong JIRA.
> Shade protobuf
> --
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 15638v2.patch, HBASE-15638.master.001.patch,
> HBASE-15638.master.002.patch, HBASE-15638.master.003.patch,
> HBASE-15638.master.003.patch, as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-15638) Shade protobuf
[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vivek Koppuru updated HBASE-15638:
--
Comment: was deleted
(was: These are all the necessary changes to split "hbase.rpc.timeout" into
"hbase.rpc.read.timeout" and "hbase.rpc.write.timeout". )
> Shade protobuf
> --
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 15638v2.patch, HBASE-15638.master.001.patch,
> HBASE-15638.master.002.patch, HBASE-15638.master.003.patch,
> HBASE-15638.master.003.patch, as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Koppuru updated HBASE-15866: -- Attachment: read-write-rpc-timeouts.patch This includes all the changes necessary to split "hbase.rpc.timeout" into "hbase.rpc.read.timeout" and "hbase.rpc.write.timeout". > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Fix For: 2.0.0 > > Attachments: read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15638) Shade protobuf
[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vivek Koppuru updated HBASE-15638:
--
Attachment: (was: read-write-rpc-timeouts.patch)
> Shade protobuf
> --
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 15638v2.patch, HBASE-15638.master.001.patch,
> HBASE-15638.master.002.patch, HBASE-15638.master.003.patch,
> HBASE-15638.master.003.patch, as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15638) Shade protobuf
[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vivek Koppuru updated HBASE-15638:
--
Attachment: read-write-rpc-timeouts.patch
These are all the necessary changes to split "hbase.rpc.timeout" into
"hbase.rpc.read.timeout" and "hbase.rpc.write.timeout".
> Shade protobuf
> --
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 15638v2.patch, HBASE-15638.master.001.patch,
> HBASE-15638.master.002.patch, HBASE-15638.master.003.patch,
> HBASE-15638.master.003.patch, as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15866 started by Vivek Koppuru. - > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Vivek Koppuru > Fix For: 2.0.0 > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. > This is fine for the general case but there are use cases where it would be > advantageous to set two separate timeouts for reads (gets, scans, perhaps > with significant server side filtering - although the new scanner heartbeat > feature mitigates where available) and mutations (fail fast under tight SLA, > resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when > handling read operations and "hbase.rpc.write.timeout" when handling write > operations. If those values are not set in the configuration, fall back to > the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC > (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up > in HTable#finishSetup. Then wherever we set up RPC with > RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or > write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our > already heavyweight set, but I think the inability to control timeouts > separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
