; >>
> > > >> Is this something we should be doing? If so, what should it look
> like?
> > > >>
> > > >>
> > > >>
> > > >> Personally, I feel like this is a pretty big gap in the project and
> > > >> would like to see an out of process tool offered. Ideally, Cassandra
> > > >> would just take care of itself, but writing a distributed repair
> > > >> scheduler that you trust to run in production is a lot harder than
> > > >> writing a single process management application that can failover.
> > > >>
> > > >>
> > > >>
> > > >> Any thoughts on this?
> > > >>
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >>
> > > >>
> > > >> Blake
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>
--
Thank you & Best Regards,
--Simon (Qingcun) Zhou
, Dec 21, 2017 at 12:33 PM, Qingcun Zhou
> wrote:
>
> > I brought up Mockito topic couple of months ago but some committers don't
> > think we should introduce more dependencies.
> >
> >
> I don't see any indication of this in the dev@ archives. There was a
re ?
> >
> > On a side note, is it ok to bring in Mockito in order to make it easier
> > writing tests ? I would like to use a Spy in order to write some tests
> > without starting the whole stack.
> >
> > Thanks,
> >
> >
> > --
> > ---------
> > Alexander Dejanovski
> > France
> > @alexanderdeja
> >
> > Consultant
> > Apache Cassandra Consulting
> > http://www.thelastpickle.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
--
Thank you & Best Regards,
--Simon (Qingcun) Zhou
still prints the old message.
>
> I'm using IntelliJ for development and building the code. I would
> appreciate any help!
>
> Thanks,
> Preetika
>
>
--
Thank you & Best Regards,
--Simon (Qingcun) Zhou
e conversation practical. There is one class I personally
> >>> really
> >>>>> want to refactor so it can be tested:
> >>>>>
> >>>>> https://github.com/apache/cassandra/blob/trunk/src/java/org/
> >>>>> apache/cassandra/net/OutboundTcpConnection.java
> >>>>>
> >>>>> There is little coverage here. Questions like:
> >>>>> what errors cause the connection to restart?
> >>>>> when are undropable messages are dropped?
> >>>>> what happens when the queue fills up?
> >>>>> Infamous throw new AssertionError(ex); (which probably bubble up to
> >>>>> nowhere)
> >>>>> what does the COALESCED strategy do in case XYZ.
> >>>>> A nifty label (wow a label you just never see those much!)
> >>>>> outer:
> >>>>> while (!isStopped)
> >>>>>
> >>>>> Comments to jira's that probably are not explicitly tested:
> >>>>> // If we haven't retried this message yet, put it back on the queue
> to
> >>>>> retry after re-connecting.
> >>>>> // See CASSANDRA-5393 and CASSANDRA-12192.
> >>>>>
> >>>>> If I were to undertake this cleanup, would there actually be support?
> >> IE
> >>>>> if
> >>>>> this going to turn into an "it aint broken. don't fix it thing" or a
> >> "we
> >>>>> don't want to change stuff just to add tests" . Like will someone
> >> pledge
> >>>>> to
> >>>>> agree its kinda wonky and merge the effort in < 1 years time?
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >> So ...:) If open a ticket to refactor OutboundTcpConnection.java to do
> >> specific unit testing and possibly even pull things out to the point
> that I
> >> can actually open a socket and to an end to end test will you/anyone
> >> support that? (it sounds like your saying I must/should make a large
> >> feature to add a test)
> >>
>
--
Thank you & Best Regards,
--Simon (Qingcun) Zhou
ameworks
> due
> > to performance reasons, overhead, and dependency management problems.
> >
> > On Thu, Mar 16, 2017 at 2:04 PM, Qingcun Zhou
> > wrote:
> >
> > > Since we're here, do we have plan to integrate with a dependency
> > injection
cause you at least counted for 8
> scenarios and you put unit test traps so that some rules are enforced. (Or
> the person changing the code has to actively REMOVE your tests asserting it
> was not or no longer is valid). Later on you (or someone else) __STILL__
> might screw the entire thing up, but at least you can now build forward.
>
> Anyway that patch on compaction was great and I am sure it improved things.
> That being said it did not add any tests :). So it can easily be undone by
> the next person who does not understand the specific issue trying to be
> addressed. Inline comments almost scream to me 'we need a test' not
> everyone believes that.
>
--
Thank you & Best Regards,
--Simon (Qingcun) Zhou
