[ https://issues.apache.org/jira/browse/HBASE-5973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273454#comment-13273454 ]
Andrew Purtell commented on HBASE-5973: --------------------------------------- +1 on backport to 0.90. > 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 > Fix For: 0.92.2, 0.96.0, 0.94.1 > > Attachments: HBASE-5973-0.90.txt, hbase-5973-0.92.txt, > hbase-5973-0.94.txt, hbase-5973-0.94.txt, hbase-5973.txt, hbase-5973.txt, > 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