[jira] [Created] (HBASE-17897) StripeStoreFileManager#nonOpenRowCompare use the wrong comparison function.

Chia-Ping Tsai created HBASE-17897: -- Summary: StripeStoreFileManager#nonOpenRowCompare use the wrong comparison function. Key: HBASE-17897 URL: https://issues.apache.org/jira/browse/HBASE-17897

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: [VOTE] Second release candidate for HBase 1.3.1 (RC1) is available

+1 (binding) * xsums/sigs OK * Can build from src * License headers/src-release files look OK * bin tarball's LICENSE is lacking [1] * Can run tests (still going, but will comment if something bad arises) * Glanced at compat report (thanks for publishing!). Thanks Yu and Andrew for looking at

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

[jira] [Created] (HBASE-17896) The FIXED_OVERHEAD of Segment is incorrect

Chia-Ping Tsai created HBASE-17896: -- Summary: The FIXED_OVERHEAD of Segment is incorrect Key: HBASE-17896 URL: https://issues.apache.org/jira/browse/HBASE-17896 Project: HBase Issue Type:

Re: [VOTE] Second release candidate for HBase 1.3.1 (RC1) is available

+1 Checked sums and signatures: ok Built from source: ok (7u80) RAT check passes: ok Unit test suite passes: ok (7u80) 1M row LTT: ok (8u102) 200M row ITBLL: ok (8u102) Phoenix master branch (+PHOENIX-3603): Compiles, most tests pass. IndexIT hangs. Probably a Phoenix thing. On Fri, Apr 7, 2017

[jira] [Created] (HBASE-17895) TestAsyncProcess#testAction fails if unsafe support is false

Chia-Ping Tsai created HBASE-17895: -- Summary: TestAsyncProcess#testAction fails if unsafe support is false Key: HBASE-17895 URL: https://issues.apache.org/jira/browse/HBASE-17895 Project: HBase