Hmmm, I didn't notice that I was running with -XX:+UseG1GC, so perhaps our
test suite is a pathological case for the default collector?
[INFO] Total time: 12:45 min
GC Time: 52.593s
Class Loader Time: 1m 26.007s
Compile Time: 10m 10.216s
I'll try without -XX:+UseG1GC later.
Cheers
Dan
On Thu,
And here I was thinking that by adding -XX:+HeapDumpOnOutOfMemoryError
anyone would be able to look into OOMEs and I wouldn't have to reproduce
the failures myself :)
Dan
On Thu, Feb 15, 2018 at 1:32 PM, William Burns wrote:
> So I must admit I had noticed a while back
So I must admit I had noticed a while back that I was having some issues
with running the core test suite. Unfortunately at the time CI and everyone
else seemed to not have any issues. I just ignored it because at the time I
didn't need to run core tests. But now that Sanne pointed this out, by
The application POM could use dependency convergence [1], but we probably
can't (and shouldn't) use the plugin in the BOM and enforce it's usage in
applications.
Dan
[1]:
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
On Thu, Feb 15, 2018 at 12:52 PM, Sebastian
This is actually how the dependency resolution (strike it out and replace
with hell) works.
In this particular example, Netty 4.1.9 is "closer" to the project you're
building than Netty 4.1.17 [1]. This happened since Maven just copy-past
the Dependency Management section from imported bom. So
Hi,
I was playing around with GRPC for a talk next month and made a mistake
that threw me a little bit and wanted to share it here to see if we can
do something about it.
My demo uses GRPC and Infinispan embedded cache (9.2.0.CR1), so I added
my GRPC dependencies and Infinispan bom dependency
Thanks Dan.
Do you happen to have observed the memory trend during a build?
After a couple more attempts it passed the build once, so that shows
it's possible to pass.. but even though it's a small sample so far
that's 1 pass vs 3 OOMs on my machine.
Even the one time it successfully completed