[
https://issues.apache.org/jira/browse/HBASE-27924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733793#comment-17733793
]
Hudson commented on HBASE-27924:
--------------------------------
Results for branch branch-3
[build #5 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/5/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/5/General_20Nightly_20Build_20Report/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/5//console].
(/) {color:green}+1 jdk11 hadoop3 checks{color}
-- For more information [see jdk11
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/5/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Remove duplicate code for NettyHBaseSaslRpcServerHandler and make the
> sentByte metrics more accurate
> ----------------------------------------------------------------------------------------------------
>
> Key: HBASE-27924
> URL: https://issues.apache.org/jira/browse/HBASE-27924
> Project: HBase
> Issue Type: Bug
> Components: netty, rpc, security
> Affects Versions: 2.6.0, 3.0.0-alpha-4, 4.0.0-alpha-1
> Reporter: chenglei
> Assignee: chenglei
> Priority: Major
> Fix For: 2.6.0, 3.0.0-beta-1
>
>
> {{NettyHBaseSaslRpcServerHandler.doResponse}} and
> {{ServerRpcConnection.doRawSaslReply}} are very similar, I think we could
> replace {{NettyHBaseSaslRpcServerHandler.doResponse}} with
> {{ServerRpcConnection.doRawSaslReply}}：
> {code:java}
> private void doResponse(ChannelHandlerContext ctx, SaslStatus status,
> Writable rv,
> String errorClass, String error) throws IOException {
> // In my testing, have noticed that sasl messages are usually
> // in the ballpark of 100-200. That's why the initial capacity is 256.
> ByteBuf resp = ctx.alloc().buffer(256);
> try (ByteBufOutputStream out = new ByteBufOutputStream(resp)) {
> out.writeInt(status.state); // write status
> if (status == SaslStatus.SUCCESS) {
> rv.write(out);
> } else {
> WritableUtils.writeString(out, errorClass);
> WritableUtils.writeString(out, error);
> }
> }
> NettyFutureUtils.safeWriteAndFlush(ctx, resp);
> }
> {code}
> {code:java}
> protected final void doRawSaslReply(SaslStatus status, Writable rv, String
> errorClass,
> String error) throws IOException {
> BufferChain bc;
> // In my testing, have noticed that sasl messages are usually
> // in the ballpark of 100-200. That's why the initial capacity is 256.
> try (ByteBufferOutputStream saslResponse = new
> ByteBufferOutputStream(256);
> DataOutputStream out = new DataOutputStream(saslResponse)) {
> out.writeInt(status.state); // write status
> if (status == SaslStatus.SUCCESS) {
> rv.write(out);
> } else {
> WritableUtils.writeString(out, errorClass);
> WritableUtils.writeString(out, error);
> }
> bc = new BufferChain(saslResponse.getByteBuffer());
> }
> doRespond(() -> bc);
> }
> {code}
> At the same time, {{NettyHBaseSaslRpcServerHandler.doResponse}} sends
> ByteBuf directly , not the unified {{RpcResponse}} , so it would not handled
> by the logic in {{NettyRpcServerResponseEncoder.write}}, which would update
> the {{MetricsHBaseServer.sentBytes}}. Using
> {{ServerRpcConnection.doRawSaslReply}} uniformly would make the
> {{MetricsHBaseServer.sentBytes}} more accurate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
