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 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:

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: PSQ processlist

2019-09-10 Thread Aleksandr Saraseka
Thank you Josh, this is very helpful. Another question - can we kill long running query in PQS somehow ? On Mon, Sep 9, 2019 at 5:09 PM Josh Elser wrote: > Not unique to PQS, see: > > https://issues.apache.org/jira/browse/PHOENIX-2715 > > On 9/9/19 9:02 AM, Aleksandr Saraseka wrote: > > Hello.

Re: PSQ processlist

2019-09-10 Thread Josh Elser
As you might already know, JDBC is "stateful" in what it does. You have a Connection, which creates Statements, and the combination of those two track queries being run. However, HTTP is a stateless protocol. As such, PQS has to cache things in memory in order to make this approach work. To