-
Bug
-
Resolution: Low Engagement
-
Medium
-
None
-
5.6.4
-
OS- Solaris 10, Confluence - 5.6.4 (EAR/WAR distribution), Tomcat 7.0.55, JDK 1.7.0_71 and Oracle 11g.
-
3
-
Severity 2 - Major
-
0
-
we are unable to shutdown tomcat due to some memory leaks in confluence. Kindly see the attached log file.
We are using OS- Solaris 10, Confluence - 5.6.4 (EAR/WAR distribution), Tomcat 7.0.55 and Oracle 11g.
Please note: we ensured the oracle driver is placed in the tomcat's lib directory, as most blogs and comments say that the JDBC drivers are the root cause of the memory leak issue.
Also some suggests to disable the tomcat's "JreMemoryLeakPreventionListener", which exist in the server.xml. However, the solution doesn't clearly explain, what would be the implications if we disable the listener. We haven't tested this solution yet. Could you please point us in right direction to get this issue resolved?
How to reproduce the issue?
on a unix environment,
1) download confluence EAR/WAR distribution
2) build and deploy the confluence war file on a shared tomcat (version 7). And setup confluence using confluence wizard.
3) configure to connect to a oracle 11g database.
4) Restore confluence site (preferably from 4.X.X).
5) Give it some time and perform some operations in the newly restored confluence site.
6) Try stopping the server. You should see some memory leak errors. (in Tomcat's Catalina.out log)
[CONFSERVER-35937] Tomcat is not shutting down properly as its trying to prevent memory leaks in Confluence
As it turns out: these log messages are not the cause of Confluence failing to shut down cleanly, although it should point to what might. Disabling the checker will also not affect Confluence's ability to shut down.
The most likely cause for why tomcat isn't exiting quickly are worker threads that haven't shut down. This is because those workers are user-level threads, and may sleep for a relatively long time before they are scheduled to wake up and detect that they should quit. However, anything longer than 30 seconds after these log messages are printed is a bug. In that case, a thread dump using jstack will tell us which threads are hanging around and keeping tomcat from exiting.
When it's enabled, different versions of Tomcat will log different levels of detail from the leak checker when they shut down. Since Confluence runs in isolation on its own Tomcat, it's never a problem that we're leaking thread locals and so on, because we're shutting down the container too, and no other web app will be affected by the leaks.
Long term: we should ship Confluence with this check disabled in our bundled Tomcat configuration, to avoid users being alarmed by these log messages.
Unfortunately no real updates at this stage. There are a number of other issue that we'll need to address before looking into this. Keep tracking this issue and we'll update this with details once we have more information.
Regards
Steve Haffenden
Confluence Bugmaster
Dinesh Srinivasan
added a comment - Any updates? Dinesh Srinivasan
added a comment - Hi Steve, It just prevents from shutting down tomcat cleanly. But every time when this issue happens, we would have to kill the process and restart tomcat.
Dinesh Srinivasan
added a comment - Hi Steve, It just prevents from shutting down tomcat cleanly. But every time when this issue happens, we would have to kill the process and restart tomcat. Thanks for raising this issue. Could you confirm whether this problem results in Confluence dying due to those memory leaks or whether this simply prevents you from shutting Tomcat down cleanly?
Regards
Steve Haffenden
Confluence Bugmaster
Hi,
At Atlassian, our goal is to ensure we’re providing the best experience for our customers. With our new Data Center strategy, Atlassian's focus is on security, compliance, and performance and is a key driver in prioritizing bugs. Closing the bugs that do not fall into those categories will allow us to focus on the ones in the most current versions of our products.
This bug is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments; this inactivity suggests a low impact.
Please note the comments on this thread are not being monitored.
You can read more about our bug fix policy here and how we prioritize bugs.
To learn more about our recent investments in Confluence Data Center, please check our public roadmap and dashboards containing recently resolved issues, current work, and future plans.
Kind regards,
Confluence Data Center