Unifying on latest java driver in the codebase and beefing up SimpleClient to be used specifically in the simulator makes sense to me. The more we exercise the driver in our testing stack the better, but to your point Benedict, the lift to get the driver itself simulator compatible seems like it wouldn't be worth it. Doubt we'd find a bunch of subtle threading and scheduling bugs in the driver (famous last words...)
On Fri, Feb 14, 2025, at 6:12 AM, Benedict Elliott Smith wrote: > One thing to consider in this discussion is integration with dtests, and in > particular the simulator. It would help to improve coverage if we had a > “client” that could operate without going over the network (or, going over a > simulated network), so that it can be controlled by the simulator. > > The SimpleClient is going to be a lot easier to achieve this with than the > Java Driver, I would guess? I would expect that getting the Java Driver > simulator-compatible would be a non-trivial undertaking in general. > > I recognise none of this has happened yet, and I don’t have a timeline for > this happening in future, but I would hate to make this future test coverage > avenue harder to explore. > > > > On 13 Feb 2025, at 20:49, Abe Ratnofsky <a...@aber.io> wrote: > > > > SimpleClient is definitely limited - it doesn't manage connection pools, > > load balancing, or error handling. I'd love to get to the point where we > > can check a driver release by running C* tests against the latest snapshot > > as part of qualification, so I'm on board for consolidating on driver 4.x > > where it's appropriate. > >
