Yes, CircleCI is typically used by most people that I know. I am not sure how 
the official builds are produced but I believe they're produced on the ASF 

Thank you for creating the ticket. 


> On Mar 24, 2019, at 6:31 PM, Stefan Miklosovic 
> <> wrote:
> Thanks Dinesh,
> I ve created a ticket for that (1). Would be nice to hear what other people
> think indeed.
> Does anybody actually run dtests on some more powerful setup and how much
> time does it all take for people? Is the CircleCI the only environment
> dtests are run in their entirety?
> (1)
> On Fri, 22 Mar 2019 at 16:37, Dinesh Joshi <>
> wrote:
>> My replies are inline –
>>> On Mar 21, 2019, at 9:00 PM, Stefan Miklosovic <
>>> wrote:
>>> the problem with the current dtests is that, ironically, when you run
>> them
>>> on too powerful machine as it is in my case, it generates so much stress
>>> via cassandra-stress tool for some tests that these nodes become
>>> unresponsive and they are killed so test can not proceed.
>> We recently ran into similar issues while trying to fix some dtests so
>> this is not entirely surprising.
>>> So in general I see three fixes:
>>> 1) Increase memory per node to something sensible, at least 1G, more is
>>> better
>>> 2) Fix the test in such way that I does not timeout even with 512M per
>> node
>>> 3) Run tests on machine with 8 cores and 16 GB as you do but that seems
>> to
>>> be like a stupid idea in general
>> I think the objective here is to get the tests as stable and fast as
>> possible. I haven't dug into this particular test so I can't say which
>> option would be the best but JIRAs are usually the best place to have such
>> discussions in the context of a patch.
>>> I can imagine this will be the issue for a lot of tests and by increasing
>>> the memory per node we could get rid of a lot problems. I was briefly
>>> checking where the memory is set in dtests per node but without success.
>> I
>>> think its job of ccm. Is there a simple way how to increase memory per
>> node
>>> in dtests?
>> I believe ccm start accepts jvm_args as an argument that would allow you
>> to specify arbitrary JVM args. Give that a try.
>> We should be judicious with such changes as it may have further
>> destabilizing effects but don't let that stop you from opening JIRAs or
>> opening PRs to fix issues. Please nudge folks in the dev list, IRC and
>> JIRAs to have them reviewed. I know I have one of your tickets already in
>> my queue and I will get to it soon :)
>> Thanks,
>> Dinesh
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to