Interesting point about the debuggability. Yes, I agree that SimpleClient (as class) should not be removed because we are using it in tests. I have already mentioned in my original e-mail that for this reason that class is not going anywhere and we still need to use it.
The cost of keeping it there is not big, sure, but we clearly see that e.g. the usage of "prepared" is buggy and it does not work. That somehow indicates to me that it kind of atrophied and nobody seems to notice which further supports my case that it is actually not used too much if it went undetected for so long. Anyway, I think that we might just look at that bug with "prepared" and fix it and keep it all there. I do not see any tests which would test cassandra-stress command, similarly what we have for nodetool in JUnit. We could cover cassandra-stress similarly, just to be sure that its invocation on the most important commands does not fail over time. ________________________________________ From: Brandon Williams <dri...@gmail.com> Sent: Wednesday, May 31, 2023 2:33 To: dev@cassandra.apache.org Subject: Re: Is simplenative in cassandra-stress still relevant? NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, May 30, 2023 at 7:15 PM Brad <bscho...@gmail.com> wrote: > If you're performing stress testing, why would you not want to use the > official driver? I've spoken to several people who all have said they've > never used simplenative mode. I agree that it shouldn't be used normally, but I'm not sure we should remove it, because we can't remove it fully: SimpleClient is still used in many tests, and I think that should continue. If you suspect any kind of native proto or driver issue it may be useful to have another implementation easily accessible to aid in debugging the problem, and the maintenance cost of keeping it in stress is roughly zero in my opinion. We can make it clear that it's not recommended for use and is intended only as a debugging tool, though. Kind Regards, Brandon
