ndimiduk commented on a change in pull request #1440: HBASE-23113: Improve and 
add additional Netty configuration for RPC.
URL: https://github.com/apache/hbase/pull/1440#discussion_r405876189
 
 

 ##########
 File path: 
hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServer.java
 ##########
 @@ -67,20 +68,49 @@
    * Tests may set this down from unlimited.
    */
   public static final String HBASE_NETTY_EVENTLOOP_RPCSERVER_THREADCOUNT_KEY =
-    "hbase.netty.eventloop.rpcserver.thread.count";
+      "hbase.netty.eventloop.rpcserver.thread.count";
   private static final int EVENTLOOP_THREADCOUNT_DEFAULT = 0;
 
+  protected static final String SERVER_TCP_BACKLOG = 
"hbase.ipc.server.tcpbacklog";
+  protected static final String SERVER_TCP_REUSEADDR = 
"hbase.ipc.server.tcpreuseaddr";
+  protected static final String SERVER_TCP_NODELAY = 
"hbase.ipc.server.tcpnodelay";
+  protected static final String SERVER_TCP_KEEPALIVE = 
"hbase.ipc.server.tcpkeepalive";
+
+  protected static final String SERVER_BUFFER_LOW_WATERMARK = 
"hbase.ipc.server.bufferlowwatermark";
+  protected static final String SERVER_BUFFER_HIGH_WATERMARK =
+      "hbase.ipc.server.bufferhighwatermark";
+
+  protected static final boolean DEFAULT_SERVER_REUSEADDR = true;
+  protected static final int DEFAULT_SERVER_TCP_BACKLOG = 1024;
 
 Review comment:
   > The TCP_BACKLOG?
   
   Sorry, no. I had this on the wrong line. I mean 
`DEFAULT_SERVER_BUFFER_LOW_WATERMARK = 1024`.
   
   > If the number of queued bytes goes above the high mark, then 
channel.isWritable will return false until the number of outstanding bytes 
falls below the low water mark.
   
   Right. So I'm asking you (and I guess @SteNicholas as well): why do we need 
to flush out the buffer down almost completely before we continue receiving 
data? Is this assuming that HBase clients are generally writing large amounts 
of data, and this to avoid thrashing back and forth between threads as we fill, 
flush, fill, flush? A setting this low means we'd have to drain the buffer 
almost entirely before returning to the user thread.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to