[ 
https://issues.apache.org/jira/browse/HBASE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080134#comment-13080134
 ] 

[email protected] commented on HBASE-3899:
------------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1257/#review1302
-----------------------------------------------------------

Ship it!


+1 from me

Todd you going to commit?

- Gary


On 2011-08-05 17:59:06, Vlad Dogaru wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/1257/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-08-05 17:59:06)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  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:
bq.  
bq.  * 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;
bq.  * make HBaseServer work according to the new semantics;
bq.  * add a unit test.  We now have testDelayedRpc{Immediate,Delayed}Response, 
testing that immediate and delayed return values work.
bq.  
bq.  Please review, thanks!
bq.  
bq.  
bq.  This addresses bug HBASE-3899.
bq.      https://issues.apache.org/jira/browse/HBASE-3899
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    src/main/java/org/apache/hadoop/hbase/ipc/Delayable.java f2ae31e 
bq.    src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java 2f7dfae 
bq.    src/test/java/org/apache/hadoop/hbase/ipc/TestDelayedRpc.java 60777cf 
bq.  
bq.  Diff: https://reviews.apache.org/r/1257/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Since the code is not used yet, it does not affect other areas of the 
codebase.  Running unit tests as we speak.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Vlad
bq.  
bq.



> 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

        

Reply via email to