-
Notifications
You must be signed in to change notification settings - Fork 277
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
[BUG] Memory leak in Web Service Listener #4657
Comments
Discussion in Slack - https://mirthconnect.slack.com/archives/C02SW0K4D/p1627916984014200 |
👀 |
After some research, it appears that the default behavior of that internal Sun ServerImpl class is to hold onto "stuck" connections forever, maybe because there's always a chance that they're not really stuck and the network layer is just taking a long time. But you can override that by setting these in your vmoptions:
When at least one of those is set, the ServerImpl will start up a separate thread to periodically (once per second, but that can be tweaked too with This issue could be resolved by having Mirth Connect set those system properties by default, unless they're overridden in VM options. |
This solution appears to work-around the problem in dev/test, and it actually looks like it's the official (if undocumented) way to prevent DOS in the built-in HTTP server. All other "real" HTTP servers do this by default. I'll be trying it in production very soon and will be able to confirm that the case-in-the-wild has been resolved as well. +1 for enabling this by default if the user hasn't already set a a value in |
After 24 hours of observation, this workaround absolutely prevents the memory leak from getting out of control. |
I see this has been fixed in 4.0.0. Was the solution to simply enable these automated clean-up threads, or has the underlying implementation been replaced with Jetty? |
…b service receiver Merge in MC/connect from bugfix/ROCKSOLID-6614-memory-leak-in-web-service-listener to development * commit 'e06b2f430baa073a1a4e80f7196d949efa3b07db': ROCKSOLID-6614 Added a fix for a memory leak in web service receiver
Describe the bug
Under certain conditions, instances of
sun.net.httpserver.HttpConnection
are retained forever after the connection has been closed.To Reproduce
Setup steps (if required). Example:
Steps to reproduce the behavior:
Expected behavior
After connections are closed, they are eventually GC'd.
Actual behavior
Connections pile-up forever until the heap is exhausted.
Environment (please complete the following information):
Workaround(s)
Re-deploying the channel allows all connections to be cleaned-up.
Additional Information
This appears to be a leak in Java's built-in SOAP server and not actually a problem with Mirth itself. I'm wondering if Mirth can possibly perform some additional setup operations to allow these connections to be cleaned-up properly.
The text was updated successfully, but these errors were encountered: