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