-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OOM in tests (Part 3) #42471
Comments
That's awesome, thanks. I will have a closer look soon. |
I have been chasing them for a while but it all depends on the extensions being around. I hope we'll be able to get to a more sustainable situation thanks to you. |
OK so I can reproduce it and this is a bit different. The issue is mostly related to Testcontainers threads and things are not leaking like crazy as they use to do (at least in my experiments). Now, our CL objects are very large and they also keep open a gazillion of zip file systems, which explains the problem (I think). |
Unfortunately, it is not easy to create a reproducer. In our real project I can easily produce an OOM (without testcontainers) unfortunately I could not extract a simple reproducer so far. I was hoping that this reproducer would at least partially solve the problem. Overall, one would expect that if each test class is executed individually and sequentially, the memory requirements would remain the same (at least after a full GC). This is not the case here. |
I pushed a first PR here ^. It improves things a bit but doesn’t really fix the reproducer. |
Do you think we could maybe organize a Google Meet call together? If you can get a heap dump and install Eclipse MAT, I could show you how to get some info and we could make progress without you sending me the heap dump? My guess is that it’s all going to be about class loaders so I won’t see any privileged info on your screen. Let me know if that could work for you. My email is open at gsmet at redhat dot com. |
Yeah, it still fails with your reproducer 3 though. There are several other things to fix. #42525 should help more and then there's the issue of Testcontainers leaking things like crazy that I'm trying to solve. |
@mschorsch FWIW, I was able to run your reproducer to completion with all these three applied:
Now, just be aware that they will probably require some discussions and I'm not convinced it will be a good move to push them to 3.14. |
@gsmet Thanks. Looks promising |
Unfortunately the Testcontainers one has little chance to be merged as it comes with some massive problem. We will have some discussions when @geoand is back from PTO. |
Hey guys, |
Yes I'm not surprised. |
I tried to make the migration guide a lot more explicit: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.13#quarkustestresource-replaced-by-withtestresource-gear-white_check_mark . @afalhambra-hivemq would the new wording have helped you? |
I also created #42700 to add more info to the Javadoc. |
Yes, definitely. Thanks a bunch. Looking forward to the fix. |
Once #42525 is in, we need to recap where we are, ideally with some real world examples |
@mschorsch we have changed the behavior of Any chance you can give it a spin? |
Awesome, thanks! |
Let's close this for now and if similar problems occur in the future, we can open a new issue |
Describe the bug
As stated in #42355 (comment), we continue to receive an OOM in our tests. I was able to create a reproducer for this.
Seems there is another memory/classloader leak.
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
oom-reproducer3.zip
./gradlew test --console=plain
Output of
uname -a
orver
Linux
Output of
java -version
Java 21
Quarkus version or git rev
Quarkus 3.13.2
Build tool (ie. output of
mvnw --version
orgradlew --version
)Gradle 8.9
Additional information
No response
The text was updated successfully, but these errors were encountered: