Re: Why we change index state to PENDING_DISABLE on RegionMovedException

2019-09-10 Thread Alexander Batyrshin
Its looks premises, but we need to do write performance evaluation old indexes vs new one before we can go with this update. > On 11 Sep 2019, at 01:15, Geoffrey Jacoby wrote: > > Just wanted to add that in the new index architecture recently introduced in > Phoenix 4.14.3 and the forthcoming

Re: Why we change index state to PENDING_DISABLE on RegionMovedException

2019-09-10 Thread Geoffrey Jacoby
Just wanted to add that in the new index architecture recently introduced in Phoenix 4.14.3 and the forthcoming 4.15, the index stays in ACTIVE state even if there's a write failure, and the index will be transparently repaired the next time someone reads from the affected keyrange. From the

Re: Why we change index state to PENDING_DISABLE on RegionMovedException

2019-09-10 Thread Vincent Poon
Normally you're right, this should get retried at the HBase layer and would be transparent. However as part of PHOENIX-4130, we have the hbase client only try the write once, so there's no chance to retry. We did that to avoid tying up rpc handlers on the server. Instead, we retry the entire

Why we change index state to PENDING_DISABLE on RegionMovedException

2019-09-10 Thread Alexander Batyrshin
As I know RegionMovedException is not a problem at all, its just notification that we need to update meta information about table regions and retry. Why we do extra work with changing state of index? 2019-09-10 22:35:00,764 WARN [hconnection-0x4a63b6ea-shared--pool10-t961] client.AsyncProcess: