aratno commented on PR #2034: URL: https://github.com/apache/cassandra-java-driver/pull/2034#issuecomment-2836947638
There are two main areas I wanted to understand better: 1. If a user has a complex application with lots of dependencies that manage state (connections to databases, local files, etc), would all those dependencies need to support CRaC? There’s a circular dependency between users expecting CRaC support and libraries providing it, and I’m wondering how you’re approaching that. 2. How much of an improvement in startup time should a user expect when restoring their application from a snapshot? How does that compare to Leyden[1]? My understanding is that Leyden will support AOT cache building without any application changes, and CRaC currently requires application support[2]. Regarding (1) above, you mentioned this on the mailing list: > Naturally it is possible to close the session object completely and create a new one, but the ideal solution would require no application changes beyond dependency upgrade. I’m concerned that restoring a driver session from a checkpoint (rather than close + re-create) could be a source for hard-to-track bugs, due to stale topology metadata, in-progress queue state, etc. Users would also be limited in where they could restore their checkpoints, since driver internal state is dependent on the local datacenter, for example. But if a restored session re-creates connections, then that’s likely going to dominate start-up time and make the gains of CRaC less visible. How are you thinking about this trade-off? [1]: https://www.morling.dev/blog/jep-483-aot-class-loading-linking/ [2]: https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md -- 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
