I think that what had been happening, is that when the JNLP Java heap size grew over time to be near the -Xmx2048m max, the container/VM was probably thrashing and falling to its knees. This was my assertion anyway, which wasn't based on facts, but seemed to help. I think that we can get facts or statistics about what is going on for such problems, by creating an Eclipse CI ticket.
Anyway, back to our current memory issue. I think that we need more memory for the Java heap and yes, we also need to check that container/VM memory size is big enough for that, as having a Java heap that is larger than available OS memory, causes thrashing. :)
Regards,
Scott
Regards,
Alwin
On 30/05/20 11:51 PM, Scott Marlow
wrote:
Hi Alwin, all,
I was just looking at the "java.lang.OutOfMemoryError: Java
heap space" failure in standalonetck-nightly-build-run-master
[1] , it looks like we have a max of 256mb used for the JNLP
process according to injectedEnvVars [2], could someone please
remind me where we are setting the environment variables for
[2]? I'm thinking that we should go higher than -Xmx256m
(512m or even 1-2g) in NLP_PROTOCOL_OPTS.
Thanks,
Scott
Hi Scott,
I will analyse the pending issues in the standalone TCK
build and ask
for help here once we have more details. Most of them would
be related
to the already created issues to remove the pruned techs.
Regards,
Alwin
On 26/05/20 8:07 PM, Scott Marlow wrote:
> Alwin also created
> https://github.com/eclipse-ee4j/jakartaee-tck/issues/293
for
> correcting the building of standalone TCKs as well.
Alwin, do you
> need help with jakartaee-tck/issues/293?