[ https://issues.apache.org/jira/browse/HBASE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078398#comment-13078398 ]
jirapos...@reviews.apache.org commented on HBASE-3899: ------------------------------------------------------ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1257/ ----------------------------------------------------------- (Updated 2011-08-02 20:00:02.348642) Review request for hbase. Changes ------- Todd, Gary, thanks for the review. I agree that returnValue is less likely to cause confusion. Summary of what changed in second iteration: * change 'response' to 'returnValue' where appropriate; * 'isReturnValueDelayed' is now a method in the Delayable interface -- if all Delayables take the boolean parameter, all of them should expose this method; * boolean parameter has the same semantics in all calls -- previously it was 'isRetValDelayed' and 'setRetValImmediately', which wasn't really a good idea :) Summary ------- Some use cases of delayed RPCs need the ability to delay the call until a further moment, but set the return value immediately. For example, if a handler calls a function returning void that might delay (a sync), the result does not depend on the function's result (since it has none). This patch enables that by making the following changes: * change the Delayable interface so that startDelay specifies whether the return value should be set immediately after call return or at the end of the delay; * make HBaseServer work according to the new semantics; * add a unit test. We now have testDelayedRpc{Immediate,Delayed}Response, testing that immediate and delayed return values work. Please review, thanks! This addresses bug HBASE-3899. https://issues.apache.org/jira/browse/HBASE-3899 Diffs (updated) ----- src/main/java/org/apache/hadoop/hbase/ipc/Delayable.java f2ae31e src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java 2f7dfae src/test/java/org/apache/hadoop/hbase/ipc/TestDelayedRpc.java 60777cf Diff: https://reviews.apache.org/r/1257/diff Testing ------- Since the code is not used yet, it does not affect other areas of the codebase. Running unit tests as we speak. Thanks, Vlad > enhance HBase RPC to support free-ing up server handler threads even if > response is not ready > --------------------------------------------------------------------------------------------- > > Key: HBASE-3899 > URL: https://issues.apache.org/jira/browse/HBASE-3899 > Project: HBase > Issue Type: Improvement > Components: ipc > Reporter: dhruba borthakur > Assignee: dhruba borthakur > Fix For: 0.92.0 > > Attachments: HBASE-3899-2.patch, HBASE-3899.patch, asyncRpc.txt, > asyncRpc.txt > > > In the current implementation, the server handler thread picks up an item > from the incoming callqueue, processes it and then wraps the response as a > Writable and sends it back to the IPC server module. This wastes > thread-resources when the thread is blocked for disk IO (transaction logging, > read into block cache, etc). > It would be nice if we can make the RPC Server Handler threads pick up a call > from the IPC queue, hand it over to the application (e.g. HRegion), the > application can queue it to be processed asynchronously and send a response > back to the IPC server module saying that the response is not ready. The RPC > Server Handler thread is now ready to pick up another request from the > incoming callqueue. When the queued call is processed by the application, it > indicates to the IPC module that the response is now ready to be sent back to > the client. > The RPC client continues to experience the same behaviour as before. A RPC > client is synchronous and blocks till the response arrives. > This RPC enhancement allows us to do very powerful things with the > RegionServer. In future, we can make enhance the RegionServer's threading > model to a message-passing model for better performance. We will not be > limited by the number of threads in the RegionServer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira