Thanks for the pointers Josh. I'm working on getting a representative
concise test to demonstrate the issue.
Meanwhile, I had one question regarding the following:
You are right that the operations in PQS should be exactly the same,
> regardless of the client you're using -- that is how this arch
Hi Omid,
Thanks for the quick reply.
When the Omid/Phoenix integration is complete, will it be released only
with Phoenix 5.x, or will it also be integrated and tested with 4.14.x
branches?
Can you comment at all on what level of testing the integration will have
had, once released? (will it be
Hi Curtis,
Omid does provide high availability for transactions, you can find the full
technical details in here:
https://www.usenix.org/conference/fast17/technical-sessions/presentation/shacham
In a nutshell, in-flight transactions in this case are aborted by the
transaction manager, they are ide
Is the OOME issue regardless of using the Java client (sqlline-thin) and
the Python client? I would like to know more about this one. If you can
share something that reproduces the problem for you, I'd like to look
into it. The only suggestion I have at this point in time is to make
sure you se
Thanks, Neelesh. It came off to me like "Phoenix is no good, Cassandra
has something that works better".
I appreciate you taking the time to clarify! That really means a lot.
On 11/2/18 8:14 PM, Neelesh wrote:
By no means am I judging Phoenix based on this. This is simply a design
trade-off (s
Hi,
Is there a best approach to ensuring high-availability for transactions?
It seems that one option when using Tephra could be through the
CFG_DATA_TX_ZOOKEEPER_QUORUM
property:
https://github.com/apache/incubator-tephra/blob/d0a1c4c295fd28e68223db220b13dc1b12b326da/tephra-core/src/main/java/org
