Re: Is HBase RPC-Handling idempotent for reads?

I believe here Suli is doing research, not building a production level feature into HBase? So the idea is the most important thing here, it must be something new. As Yu Li said above, speculative execution is a usually used in computation framework such MR, so it is something new for a storage

Re: Is HBase RPC-Handling idempotent for reads?

Yeah, neat idea now that I understand the big picture :) Instead of trying to do this purely server-side, have you considered a first "wag" at a solution of hooking into the existing RPC quota work? Presently, in the context of a user's RPCs, quotas only limit the number of RPCs that user

Re: Is HBase RPC-Handling idempotent for reads?

I see, some priority-based preemptive scheduling. bq. if it requires I/O resources that are not allocated to it Easy to tell whether the request misses the cache and requires IO operation, but what's the standard of "not allocated"? Some kind of timeout? Anyway, interesting topic and let us know

Re: Is HBase RPC-Handling idempotent for reads?

On Sun, Apr 9, 2017 at 11:14 PM, Yu Li wrote: > Correct me if I'm wrong, but I think we should assume no other but the > single operation when checking whether it's idempotent. Similar to the > wikipedia > example : "A

Re: Is HBase RPC-Handling idempotent for reads?

Yes. In the context to the underlying physical region or database,. read is idempotent. Thanks Jerry On Apr 9, 2017 9:15 PM, "Yu Li" wrote: > Correct me if I'm wrong, but I think we should assume no other but the > single operation when checking whether it's idempotent.

Re: Is HBase RPC-Handling idempotent for reads?

Correct me if I'm wrong, but I think we should assume no other but the single operation when checking whether it's idempotent. Similar to the wikipedia example : "A function looking up a customer's name and address in a database

Re: Is HBase RPC-Handling idempotent for reads?

Again, it depends on how you abort and 'idempotent' can have different definitions. For example, even if you are only concerned about read, there are resources on the HRegion that the read touches or acquires (scanner, lock, mvcc etc) that hopefully will be cleaned/releases with the abort. Or you

Re: Is HBase RPC-Handling idempotent for reads?

I think this depends on how you model the problem. At server side, if you re-execute a read operation with a new mvcc, then you may read a value that should not be visible if you use the old mvcc. If you define this as an error then I think there will be conflicts. But at client side, there is

Re: Is HBase RPC-Handling idempotent for reads?

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) wrote: > It depends on how you about the rpc request. For hbase, there

Re: Is HBase RPC-Handling idempotent for reads?

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

Re: Is HBase RPC-Handling idempotent for reads?

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

Re: Is HBase RPC-Handling idempotent for reads?

+1 to that one, Jerry :). I think we're missing some context, Suli. Also, I don't know of any code path in which an RPC would be partially processed and then returned to the queue. Calls go from wire -> queue -> handler, they can't move backwards. They either move forward or throw an

Re: Is HBase RPC-Handling idempotent for reads?

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 wrote: > Hi, > > I am wondering, for read

Is HBase RPC-Handling idempotent for reads?

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