hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 杨苏立 Yang Su Li <yangs...@gmail.com>
Subject Re: Is HBase RPC-Handling idempotent for reads?
Date Mon, 10 Apr 2017 01:52:46 GMT
We are only concerned about read operations here. Are you suggesting they
are completely idempotent?
Are there any read-after-write conflicts?

Thanks

Sui

On Sun, Apr 9, 2017 at 8:48 PM, 张铎(Duo Zhang) <palomino219@gmail.com> wrote:

> It depends on how you about the rpc request. For hbase, there will be no
> write conflict, but a write operation can only be finished iff all the
> write operations with a lower mvcc number have been finished. So if you
> just stop a write operation without recovering the mvcc(I do not know how
> to recover but I think you need to something...) then the writes will be
> stuck.
>
> And one more thing, for read operation you may interrupt it at any time,
> but for write operation, I do not think you can re-execute it with a new
> mvcc number if the WAL entry has already been flushed out. That means, the
> re-execution process will be different if you about the write operation at
> different stages.
>
> Thanks.
>
> 2017-04-10 6:47 GMT+08:00 杨苏立 Yang Su Li <yangsuli@gmail.com>:
>
> > 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 <jerryjch@gmail.com> 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 <yangsuli@gmail.com>
> > 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
> >
>



-- 
Suli Yang

Department of Physics
University of Wisconsin Madison

4257 Chamberlin Hall
Madison WI 53703

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message