> I think that Cassandra should have some basic tool available to stress-test > itself > I do not think that the current cassandra-stress is completely "useless" Think there was an implication in my statement I didn't intend. I wasn't talking about not having *any* stress tool as the reference in our code-base, just trying to poke a bit at whether or not the one we have, which isn't maintained, should continue to be the one we use going forward.
I'd be fine with us collectively investing more energy into cassandra-stress, or seeing about reaching out to the tlp folks about tlp-stress replacing it as the default, or NoSQLBench, or some cassandra-stress argument compatible wrapper over one of them so things can migrate transparently, etc. On Wed, May 31, 2023, at 11:42 AM, Miklosovic, Stefan wrote: > Well this is a completely different kind of discussion, Josh, let's explore > it, shall we? > > I think that Cassandra should have some basic tool available to stress-test > itself. Why not? I do not want to depend on some 3rd party tools even if they > might be objectively better. I do not think that the current cassandra-stress > is completely "useless". It is doing its job, more or less. If a user wants > to have something more advanced she is welcome to use that but I do not like > that we are trying to outsource the basic tooling outside of the project. > > As I see it, we just spice it up with some tests to be sure that it will not > break without us knowing it and that's it. The fact that it is not actively > contributed to does not necessarily make it eligible for deletion as a whole. > > Anyway, I am not calling the shots here, if a community decides it has to go > so it will but I would be said to see it. > > Regards > > > ________________________________________ > From: Josh McKenzie <jmcken...@apache.org> > Sent: Wednesday, May 31, 2023 15:15 > To: dev > 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. > > > > 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<mailto: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<mailto:dri...@gmail.com>> > Sent: Wednesday, May 31, 2023 2:33 > To: dev@cassandra.apache.org<mailto: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<mailto: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 > >
