hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: Coprocessor execution with bulk data
Date Thu, 08 Mar 2012 20:38:38 GMT
+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.

async RPC would be great too. asynchbase is a good example of such an API.

-- Lars

 From: Andrew Purtell <apurtell@apache.org>
To: "user@hbase.apache.org" <user@hbase.apache.org> 
Sent: Thursday, March 8, 2012 10:56 AM
Subject: Re: Coprocessor execution with bulk data
You can increase the RPC timeout period to keep this from happening.

But maybe it makes sense to give our RPC a "keepalive" option for calls that may run for a
long time (like execCoprocessor)? 

Or fold this into a broader rework into a proper async RPC model.
Best regards,

    - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

----- Original Message -----
> From: Stack <stack@duboce.net>
> To: user@hbase.apache.org
> Cc: 
> Sent: Thursday, March 8, 2012 9:14 AM
> Subject: Re: Coprocessor execution with bulk data
> On Wed, Mar 7, 2012 at 10:59 PM, raghavendhra rahul
> <raghavendhrarahul@gmail.com> 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 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
> Usually this means the client has gone away perhaps because the
> processing was taking longer than the rpctimeout?  Does the above
> happen every time?
> St.Ack
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message