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