I remember running into cases where the main user of an internal API that I wanted to clean up was stress. It's a big chunk of code and the indirect cost of keeping it around is not zero even if it's not being actively improved.
On Wed, May 31, 2023 at 10:43 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> 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 > > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
