RE: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] > Subject: Re: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor > Am 11.07.2018 um 16:22 schrieb Martin Knoblauch: > > Now it might be, that we are just using the StatementFinalizer in a wrong > > manner. And what we see is expected behavior. Below is our pool > > configuration. Maybe something is just missing :-) > The docs in the interceptor says one has to call close on the > connection, that the statements created. Does your application call > close on the connection? This section of the doc includes a decent model that your webapp code should be following: http://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html# Random_Connection_Closed_Exceptions Proper use of a finally block is critical. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. smime.p7s Description: S/MIME cryptographic signature
Re: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor
Am 11.07.2018 um 16:22 schrieb Martin Knoblauch: Hi, while analyzing some heap dump for other reasons, I found that our application is apparently aggregating a considerable amount of memory in "org.apache.tomcat.jdbc.pool.TrapException", which is never cleaned by GC. Digging deeper, it seems that the entries of the "statements" linked list in the StatementFinalizer are never removed from the list, so after three weeks of lifetime one ends up with a list of 7 million entries, each 80 bytes. Now it might be, that we are just using the StatementFinalizer in a wrong manner. And what we see is expected behavior. Below is our pool configuration. Maybe something is just missing :-) The docs in the interceptor says one has to call close on the connection, that the statements created. Does your application call close on the connection? Regards, Felix We are at Tomcat 8.0.36 (yeah, I know, but that is the version we have to use) and Java 8 (1.8.0_171). Underlying DB is Oracle 12.1.0.2 and we are using the latest "ojdbc7.jar" from Oracle. Thanks Martin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor
Hi, while analyzing some heap dump for other reasons, I found that our application is apparently aggregating a considerable amount of memory in "org.apache.tomcat.jdbc.pool.TrapException", which is never cleaned by GC. Digging deeper, it seems that the entries of the "statements" linked list in the StatementFinalizer are never removed from the list, so after three weeks of lifetime one ends up with a list of 7 million entries, each 80 bytes. Now it might be, that we are just using the StatementFinalizer in a wrong manner. And what we see is expected behavior. Below is our pool configuration. Maybe something is just missing :-) We are at Tomcat 8.0.36 (yeah, I know, but that is the version we have to use) and Java 8 (1.8.0_171). Underlying DB is Oracle 12.1.0.2 and we are using the latest "ojdbc7.jar" from Oracle. Thanks Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
