[
https://issues.apache.org/jira/browse/HBASE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069312#comment-13069312
]
jirapos...@reviews.apache.org commented on HBASE-3899:
------------------------------------------------------
bq. On 2011-07-21 21:46:40, Todd Lipcon wrote:
bq. > src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java, lines 244-245
bq. > <https://reviews.apache.org/r/1174/diff/1/?file=26654#file26654line244>
bq. >
bq. > are these two booleans totally orthogonal? or should we really have
a tri-state enum? [not sure yet]
Yes, the response is send as soon as endDelay is called (I changed the API).
bq. On 2011-07-21 21:46:40, Todd Lipcon wrote:
bq. > src/test/java/org/apache/hadoop/hbase/ipc/TestDelayedRpc.java, lines
72-74
bq. > <https://reviews.apache.org/r/1174/diff/1/?file=26656#file26656line72>
bq. >
bq. > this test seems pretty timing-dependent. I wouldn't trust that the
sleeps are enough to force the order you expect
I am not sure how otherwise to enforce the order. Do you have any suggestions?
bq. On 2011-07-21 21:46:40, Todd Lipcon wrote:
bq. > src/test/java/org/apache/hadoop/hbase/ipc/TestDelayedRpc.java, lines
87-98
bq. > <https://reviews.apache.org/r/1174/diff/1/?file=26656#file26656line87>
bq. >
bq. > I don't follow. Isn't the idea here that the rpc handler would
return an unused value immediately (eg return -1) and then another thread would
_later_ set the return value?
bq. >
bq. > i.e I'd have expected the function implementatoin to be something
like:
bq. >
bq. > public int test(boolean delay) {
bq. > if (!delay) { return UNDELAYED; }
bq. > final Delayable call = rpcServer.getCurrentCall();
bq. > call.startDelay();
bq. > new Thread() {
bq. > public void run() {
bq. > call.endDelay(DELAYED);
bq. > }
bq. > }
bq. > return 0xDEADBEEF; // this return value should not go back to
client
bq. > }
bq. >
bq. > what am I missing?
Ah, I was overlooking setting the return value. The endDelay function now takes
a Writable as its parameter. Will upload a new patch.
- Vlad
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1174/#review1159
-----------------------------------------------------------
On 2011-07-22 00:17:13, Vlad Dogaru wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1174/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-07-22 00:17:13)
bq.
bq.
bq. Review request for hbase.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Free up RPC server Handler thread if the called routine specifies the call
should be delayed. The RPC client sees no difference, changes are server-side
only. This is based on the previous submitted patch from Dhruba.
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/test/java/org/apache/hadoop/hbase/ipc/TestDelayedRpc.java
PRE-CREATION
bq. src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java 0da7f9e
bq. src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java 61d3915
bq. src/main/java/org/apache/hadoop/hbase/ipc/Delayable.java PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/1174/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Unit tests run. Also, the patch includes a new unit test.
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.94.0
>
> Attachments: 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
