We are trying to implement speculative rpc handling for our workloads. So we want allow RPC Handler to stop executing an RPC call, put it back to the queue, and later re-execute it.
If at time t1, we execute and RPC call half way, aborts, and put the call back to the queue. Then at time t2 another RPC handler picks the call and re-execute it. I understand that we might get a different mvcc number and different results at t2 compared to we execute it at t1. My question is that: would this situation any different compared to the situation where the call was never executed at t1, and is executed at t2 for the first time. My guess is that since at t1 we may already gotten an mvcc number, so it might potentially cause some write conflicts and certain write operations to retry. But correctness wise, is there any difference? Thanks a lot! Suli On Sun, Apr 9, 2017 at 5:14 PM, Jerry He <[email protected]> wrote: > I don't know what your intention and your context are. > > You may get a different mvcc number and get different results next time > around if there are concurrent writes. > > Thanks, > > Jerry > > On Sun, Apr 9, 2017 at 12:48 PM 杨苏立 Yang Su Li <[email protected]> wrote: > > > Hi, > > > > I am wondering, for read requests like Get/MultiGet/Scan, is the RPC > > handling idempotent in HBase? > > > > More specifically, if in the middle of RPC handling we stop the handling > > threads, puts the RPC call back to the queue, and later another RPC > Handler > > picks up this call and starts all over again, will the result be the same > > as if this call is being handled for the first time now? Or are their any > > unexpected side effects? > > > > Thanks! > > > > Suli > > > > -- > > Suli Yang > > > > Department of Physics > > University of Wisconsin Madison > > > > 4257 Chamberlin Hall > > Madison WI 53703 > > > -- Suli Yang Department of Physics University of Wisconsin Madison 4257 Chamberlin Hall Madison WI 53703
