Refreshing /monitoring page causes used jdbc connections leak if installed as jira plugin

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install as Jira plugin.
2. Refresh /monitoring page 10 times.
3. Observe that used connections number grew by ~10. After 10 hours the
used connections are still there even if there's 50 of them.

What is the expected output? What do you see instead?
Number of used connections should decrease over time.

What version of the product are you using? On what application server, JDK,
operating system?
jira-javamelody-1.15.1.jar
jira 4.0.1

Please provide any additional information below.

Original issue reported on code.google.com by terraf...@gmail.com on 31 May 2010 at 9:34

[GoogleCodeExporter]

opened jdbc connections, date and stack trace when opened

5/31/10 11:15 AM
$Proxy581.getConnection(Unknown Source)
net.bull.javamelody.JavaInformations.buildDataBaseVersion(JavaInformations.java:
368)
net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:180)
net.bull.javamelody.MonitoringFilter.doMonitoring(MonitoringFilter.java:490)
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:347)
net.bull.javamelody.JiraMonitoringFilter.doFilter(JiraMonitoringFilter.java:77)
com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPl
uginFilter.java:74)
com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilte
rChain.java:42)
com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(
ServletFilterModuleContainerFilter.java:55)
com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(
ServletFilterModuleContainerFilter.java:41)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
com.atlassian.jira.web.filters.CurlyQuotesFilter.doFilter(CurlyQuotesFilter.java
:24)
com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:3
1)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
com.atlassian.core.filters.cache.AbstractCachingFilter.doFilter(AbstractCachingF
ilter.java:33)
com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:3
1)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
com.atlassian.core.filters.encoding.AbstractEncodingFilter.doFilter(AbstractEnco
dingFilter.java:41)
com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:3
1)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
com.atlassian.jira.startup.JiraStartupChecklistFilter.doFilter(JiraStartupCheckl
istFilter.java:72)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2
13)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
72)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108
)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:581)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:873)
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:665)
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:52
8)
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorker
Thread.java:81)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:68
9)
java.lang.Thread.run(Thread.java:619)

Original comment by terraf...@gmail.com on 31 May 2010 at 11:43

[GoogleCodeExporter]

Many thanks for the issue.
In fact this does not cause a jdbc connections leak, but it is a bug in the 
count of
jdbc connections by javamelody when used as a jira plugin and only for the
connections in "/monitoring" page.

I reproduced it and in fact, openings of jdbc connections in the "/monitoring" 
page
were counted twice and closings of jdbc connections in this page were counted 
only once.
I fixed this to count openings and closing once in the "/monitoring" page when 
used
as a jira plugin.
This is commited in trunk (revision 928) and ready for the next release (v1.16, 
in a
few days).

Original comment by evernat@free.fr on 31 May 2010 at 11:52

• Changed state: Fixed

[GoogleCodeExporter]

Great.

Original comment by terraf...@gmail.com on 31 May 2010 at 1:48