> The main issue I see with maintaining the SimpleClient in cassandra-stress is > the burden it puts on a user to understand the options available when > connecting with *-mode*: How frequently do we expect users or devs to use the built-in cassandra-stress tool? Between tlp-stress and NoSQLBench, it's not clear to me that keeping cassandra-stress (which has been largely unmaintained for years as I understand it?) is the best option.
On Wed, May 31, 2023, at 9:00 AM, Brad wrote: > We all agree that we're not suggesting removing SimpleClient from Cassandra, > just from its use in cassandra-stress. > > For debugging the native transport protocol, in addition to the standalone > Java Driver, there are the python drivers and ODBC drivers which can be > exercised with cqlsh and Intellij respectively. Are they not sufficient? > > The main issue I see with maintaining the SimpleClient in cassandra-stress is > the burden it puts on a user to understand the options available when > connecting with *-mode*: > >> > cassandra-stress help -mode >> >> Usage: -mode native [unprepared] cql3 [compression=?] [port=?] [user=?] >> [password=?] [auth-provider=?] [maxPending=?] [connectionsPerHost=?] >> [protocolVersion=?] >> >> OR >> >> Usage: -mode simplenative [prepared] cql3 [port=?] >> >> >> >> .... >> > > > A user trying to determine how to specify credentials for usr/pwd is > presented with the option to use simplenative and prepared statements (which > appear broken). It can lead down a rabbit hole of sparse documentation > trying to figure out what the simplenative option is, and is better than > cql3? > > > > > > On Wed, May 31, 2023 at 1:58 AM Miklosovic, Stefan > <stefan.mikloso...@netapp.com> wrote: >> 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
