[
https://issues.apache.org/jira/browse/HBASE-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227333#comment-13227333
]
Himanshu Vashishtha commented on HBASE-5543:
--------------------------------------------
What is the scope of the uuid token in the Coprocessor context. The current
approach is to subdivide the calls in terms of regions; then submit a Callable
object for each of these Regions; obtain a Future object on each of these calls
and block until all of them have returned some result.
So, a uuid from the client side server proxy object, or a list of uuids from
all the involved regions, or something more elegant which I am missing. Please
suggest. Thanks.
> Add a keepalive option for IPC connections
> ------------------------------------------
>
> Key: HBASE-5543
> URL: https://issues.apache.org/jira/browse/HBASE-5543
> Project: HBase
> Issue Type: Improvement
> Components: client, coprocessors, ipc
> Reporter: Andrew Purtell
>
> On the user list someone wrote in with a connection failure due to a long
> running coprocessor:
> {quote}
> On Wed, Mar 7, 2012 at 10:59 PM, raghavendhra rahul wrote:
> 2012-03-08 12:03:09,475 WARN org.apache.hadoop.ipc.HBaseServer: IPC Server
> Responder, call execCoprocessor([B@50cb21, getProjection(), rpc version=1,
> client version=0, methodsFingerPrint=0), rpc version=1, client version=29,
> methodsFingerPrint=54742778 from 10.184.17.26:46472: output error
> 2012-03-08 12:03:09,476 WARN org.apache.hadoop.ipc.HBaseServer: IPC Server
> handler 7 on 60020 caught: java.nio.channels.ClosedChannelException
> {quote}
> I suggested in response we might consider give our RPC a keepalive option for
> calls that may run for a long time (like execCoprocessor).
> LarsH +1ed the idea:
> {quote}
> +1 on "keepalive". It's a shame (especially for long running server code) to
> do all the work, just to find out at the end that the client has given up.
> Or maybe there should be a way to cancel an operation if the clients decides
> it does not want to wait any longer (PostgreSQL does that for example). Here
> that would mean the server would need to check periodically and coprocessors
> would need to be written to support that - so maybe that's no-starter.
> {quote}
--
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
