hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5973) Add ability for potentially long-running IPC calls to abort if client disconnects
Date Wed, 09 May 2012 22:55:52 GMT

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

Todd Lipcon commented on HBASE-5973:

bq. Is the above method used anywhere ?

No, good point. It was used in an earlier rev but I took it out.

bq. Can throwExceptionIfCallerDisconnected() be added to Delayable ? There is only one implementation
of Delayable:

It doesn't make sense inside an interface called Delayable. We could get rid of Delayable
entirely (I considered that) but decided to keep it separate since it's a nice general interface
with no tying to IPC currently.
> Add ability for potentially long-running IPC calls to abort if client disconnects
> ---------------------------------------------------------------------------------
>                 Key: HBASE-5973
>                 URL: https://issues.apache.org/jira/browse/HBASE-5973
>             Project: HBase
>          Issue Type: Improvement
>          Components: ipc
>    Affects Versions: 0.90.7, 0.92.1, 0.94.0, 0.96.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hbase-5973.txt
> We recently had a cluster issue where a user was submitting scanners with a very restrictive
filter, and then calling next() with a high scanner caching value. The clients would generally
time out the next() call and disconnect, but the IPC kept running looking to fill the requested
number of rows. Since this was in the context of MR, the tasks making the calls would retry,
and the retries wuld be more likely to time out due to contention with the previous still-running
scanner next() call. Eventually, the system spiraled out of control.
> We should add a hook to the IPC system so that RPC calls can check if the client has
already disconnected. In such a case, the next() call could abort processing, given any further
work is wasted. I imagine coprocessor endpoints, etc, could make good use of this as well.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message