You could use async API such as asynchbase -that you've mentioned- on your client side; or you can write your CP in a async way. IMHO it mostly depends on your API contract and its guarantees, whatever the client.
On Sat, Jul 20, 2013 at 3:28 AM, Ted Yu <[email protected]> wrote: > coprocessorExec() calls connection.processExecs(). > > In HConnectionManager, we have this code (0.94) : > > Future<R> future = pool.submit( > new Callable<R>() { > ... > futures.put(r, future); > } > for (Map.Entry<byte[],Future<R>> e : futures.entrySet()) { > try { > e.getValue().get(); > > If I understand your case correctly, you want shorter timeout. > We should be able to utilize the following method of Future: > > V < > http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html> > get(long timeout, > TimeUnit < > http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/TimeUnit.html > > > unit) > > Cheers > > > On Fri, Jul 19, 2013 at 5:23 PM, Kim Chew <[email protected]> wrote: > > > Suppose I have a table "foo" which spans four RS, > > RS1 > > RS2 > > RS3 > > RS4 > > > > I have deployed my coprocessor to table "foo" and I invoke my coprocessor > > using Batch.call and pass this object to HTable's "coprocessorExec". > > > > Some how RS2 has died, it seems like I am at the mercy of the RPC after > it > > has exhausted its attempts to try to talk to RS2 after 10 tries, in the > > mean time, my client which invokes the coprocessor keeps waiting. > > > > Is there a way that I could detect a dead RS much faster? May be adding a > > "timeout" argument to "coprocessorExec" in the future? > > > > Correct me if I was wrong, "coprocessorExec" does not seems to be async. > If > > I want to make by call to the coprocessor async, do I have to resort to > > something like asynchbase? > > > > TIA > > > > Kim > > > -- Adrien Mogenet http://www.borntosegfault.com
