Hi Abe,
I would expect that if the control connection is terminated, on the next
request it would be re-established including the handshake you mention.
This shouldn't be different from a connection being broken due to
network error. In the POC PR I am calling just `DriverChannel.close()`,
though as I see this sends a graceful termination to the wire as well.
> Would it be possible to have a separate CqlSession implementation
that includes CRaC's checkpoint and restore hooks[2] to close and open
the session at the appropriate times
That is an option, though how convenient would that be for use? In
Spring Boot case, we would could add Spring Boot-specific module that
would 'override' the type that should be used, with a dependency on a
'generic' module implementing the session. I think that this could be
transparent enough, but if these are both managed as third-party module,
it would be almost easier to just keep the `CassandraSessionLifecycle`
managing the connections 'from the outside'. The fragility problem
remains (modifications that break the third-party module are not
observed immediately, e.g. in a testsuite). The advantage is in being
able to eventually take the unmodified class into the driver.
For non-framework use-cases, I think that this is a bigger issue: since
CqlSession.builder().withWhatever(...).build() will always return the
`DefaultSession` the code would have to be modified to use a different
builder. There's no way to 'configure' this (reflection, service
loader...); the TPM would have a `CracableSessionBuilder` with a
non-trivial override of `SessionBuilder.buildDefaultSessionAsync` and
the application would have to change its code to use it.
Thanks for your thoughts!
Radim
[1]
https://github.com/spring-projects/spring-boot/pull/44505/files#diff-780d2cdd9f860039f0a5a198303af2fe04ea05991ec15e63b09d3f094e3ea8a9R92
On 10. 03. 25 17:28, Abe Ratnofsky wrote:
Caution: This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.
Hey Radim, thanks for bringing this to the list.
In general, I'm supportive of the second option you shared ("Exposing
neutral methods") but want to make sure I understand how CRaC would
work in practice.
Could you clarify this part:
> 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.
CRaC doesn't support checkpointing with open sockets, and the
Cassandra client protocol requires a few roundtrips after connection
establishment before a session can be used[1]. Would it be possible to
have a separate CqlSession implementation that includes CRaC's
checkpoint and restore hooks[2] to close and open the session at the
appropriate times? This CRaC implementation could live as a
third-party module initially as it is proven out.
[1]:
https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L176
[2]:
https://docs.azul.com/core/crac/crac-guidelines#implementing-crac-resource
