Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=GjTxQr8CbU2W/S7M09fuUpzDtBbjdKpu9/Lk/dZlWw6gYD9wTIyeqsCtKp/16ih6gI5jQsUBTo+0IFwvM0FIbKEQL/jegU9kz0G1wDbe9ZR/b1SHq7rbHPXjCCrcq0SluPkTN1K49WRBkVKHAkQ98p6wZhkwSVKAM7j3wuaBtiY=;
References: 
 <CAHeyn2u5cu=YmTSjL4u0T1oH8vL+mg9Ud+2nGjNB-gEkX6N_Bg@mail.gmail.com>
 <CADcMMgHAW_x9YqAqMwgP8Ya8aCMAsHXJS7wo_YAO8bD-BnCOBA@mail.gmail.com>
 <1331232961.67605.YahooMailNeo@web164501.mail.gq1.yahoo.com>
Message-ID: <1331239118.73963.YahooMailNeo@web121703.mail.ne1.yahoo.com>
Date: Thu, 8 Mar 2012 12:38:38 -0800 (PST)
From: lars hofhansl <lhofhansl@yahoo.com>
Reply-To: lars hofhansl <lhofhansl@yahoo.com>
Subject: Re: Coprocessor execution with bulk data
To: "user@hbase.apache.org" <user@hbase.apache.org>,
  Andrew Purtell <apurtell@apache.org>
In-Reply-To: <1331232961.67605.YahooMailNeo@web164501.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="1001534069-1803669202-1331239118=:73963"

--1001534069-1803669202-1331239118=:73963
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+1 on "keepalive". It's a shame (especially for long running server code) t=
o do all the work,=0Ajust to find out at the end that the client has given =
up.=0A=0AOr maybe there should be a way to cancel an operation if the clien=
ts decides it does not want to wait any longer (PostgreSQL does that for ex=
ample).=0AHere 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.=0A=0A=0Aasync RPC would be great too. asynchbase is a good exa=
mple of such an API.=0A=0A=0A-- Lars=0A=0A=0A=0A___________________________=
_____=0A From: Andrew Purtell <apurtell@apache.org>=0ATo: "user@hbase.apach=
e.org" <user@hbase.apache.org> =0ASent: Thursday, March 8, 2012 10:56 AM=0A=
Subject: Re: Coprocessor execution with bulk data=0A =0AYou can increase th=
e RPC timeout period to keep this from happening.=0A=0ABut maybe it makes s=
ense to give our RPC a "keepalive" option for calls that may run for a long=
 time (like execCoprocessor)? =0A=0A=0AOr fold this into a broader rework i=
nto a proper async RPC model.=0A=A0=0ABest regards,=0A=0A=0A=A0 =A0 - Andy=
=0A=0AProblems worthy of attack prove their worth by hitting back. - Piet H=
ein (via Tom White)=0A=0A=0A=0A----- Original Message -----=0A> From: Stack=
 <stack@duboce.net>=0A> To: user@hbase.apache.org=0A> Cc: =0A> Sent: Thursd=
ay, March 8, 2012 9:14 AM=0A> Subject: Re: Coprocessor execution with bulk =
data=0A> =0A> On Wed, Mar 7, 2012 at 10:59 PM, raghavendhra rahul=0A> <ragh=
avendhrarahul@gmail.com> wrote:=0A>>=A0 2012-03-08 12:03:09,475 WARN org.ap=
ache.hadoop.ipc.HBaseServer: IPC Server=0A>>=A0 Responder, call execCoproce=
ssor([B@50cb21, getProjection(), rpc version=3D1,=0A>>=A0 client version=3D=
0, methodsFingerPrint=3D0), rpc version=3D1, client version=3D29,=0A>>=A0 m=
ethodsFingerPrint=3D54742778 from 10.184.17.26:46472: output error=0A>>=A0 =
2012-03-08 12:03:09,476 WARN org.apache.hadoop.ipc.HBaseServer: IPC Server=
=0A>>=A0 handler 7 on 60020 caught: java.nio.channels.ClosedChannelExceptio=
n=0A> =0A> =0A> Usually this means the client has gone away perhaps because=
 the=0A> processing was taking longer than the rpctimeout?=A0 Does the abov=
e=0A> happen every time?=0A> =0A> St.Ack=0A>
--1001534069-1803669202-1331239118=:73963--