absurdfarce commented on PR #2034:
URL: 
https://github.com/apache/cassandra-java-driver/pull/2034#issuecomment-2837428237

   I don't claim any familiarity with the current work on CRaC but I have some 
concerns here that aren't different from what @lukasz-antoniak and @aratno are 
talking about above.  The question with in-flight requests isn't simply whether 
the driver will retry them; we use counts of in-flight requests as a proxy for 
the load on a node in the default load balancing policy.  The disconnect 
between the (potentially very stale) data represented by in-flight requests and 
snapshot time vs. the current state of a system could very easily lead to some 
strange LBP operations.
   
   You'd almost be better off somehow capturing the driver state after 
establishing a control connection but before any individual connections are 
established... but that brings you into the areas @aratno was referring to (or 
at least I think he was).  The driver gathers a fair amount of metadata 
information when it establishes a control connection to the cluster; if we 
include this data in any kind of snapshot state it would have to be revalidated 
when we (re)connect anyway.  But if we're already doing such a revalidation is 
there... a benefit to pre-loading it in the first place?  So much of what the 
control connection does is built up from information it gets from the server.. 
it just seems hard to imagine how much of it could be safely cached in a way 
that would give you clear performance wins.
   
   I also haven't spent any time looking at what Project Leyden is doing but it 
does seem like AOT classloading might be a reasonable way to get some level of 
performance gain without delving too far into the handling of information we 
get from the cluster.  I'm very interested to hear how these approaches compare 
in your thinking @rvansa.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For additional commands, e-mail: pr-h...@cassandra.apache.org

Reply via email to