If the distributedTest jobs are swapping then we have a bigger problem than
just this test. We can crank down on the number of parallel jobs and see
if that relieves the memory pressure, or we can check for machine types
with more memory.
I can look at this on Monday, or maybe ping @Sean Goller
So far Jens and I are unable to reproduce these test failures [1]. This
does not appear to be a test or java code problem. Based on google searches
[2] [3], the cause might be either:
1) the distributed test job is out of swap space when the Tomcat/Jetty
tests run
2) the /proc/sys/vm/overcommit_m
I can work with you on this if you're still blocked.
--Jens
On Tue, Aug 20, 2019 at 4:12 PM Kirk Lund wrote:
> Does anyone know how to debug geode-assembly Jetty dunit tests that fail to
> launch modify_war?
>
> It passes 100% locally in intellij and with gradle cli. It only fails in
> concours
Does anyone know how to debug geode-assembly Jetty dunit tests that fail to
launch modify_war?
It passes 100% locally in intellij and with gradle cli. It only fails in
concourse PR precheckin.
Right now, this is the last thing blocking me from submitting a non-draft
PR to move all log4j-core code
