Tomcat connection pool ThrowableCallStack issue
up vote
0
down vote
favorite
Found following logs sometimes in Tomcat8.5. When we observe error
stacktrace we didn't found any connection leak in the code but the log
is captured for sometimes. I am unable to recognize whether this is
the indication to connection leak or any other issue.
Pooled object created 2018-11-13 11:00:01 -0800 by the following code
has not been returned to the pool:
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot at
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack.fillInStackTrace(ThrowableCallStack.java:71)
at org.apache.tomcat.dbcp.pool2.impl.DefaultPooledObject.allocate(DefaultPooledObject.java:192)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:455)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:361)
at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1543)
at com.sample.test.db.SlaveDBConnection.initiateConnection(SlaveDBConnection.java:40)
at com.sample.test.db.SlaveDBConnection.<init>(SlaveDBConnection.java:25)
at com.sample.test.db.DBFactory.getDBObject(DBFactory.java:80)
at com.sample.test.app.model.dao.UserDAOImpl.getUserData(UserDAOImpl.java:1795)
at org.apache.jsp.getData_jsp._jspService(getData_jsp.java:298)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:443)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.MFilter.doFilter(MFilter.java:52)
Here what is ment by
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot and when
do we get this issue. And how can we reproduce this issue?
tomcat connection-pooling tomcat8.5
edited Nov 19 at 8:37
Selaron
974714
asked Nov 16 at 13:10
Yella Goud
47310
add a comment |
up vote
0
down vote
favorite
Found following logs sometimes in Tomcat8.5. When we observe error
stacktrace we didn't found any connection leak in the code but the log
is captured for sometimes. I am unable to recognize whether this is
the indication to connection leak or any other issue.
Pooled object created 2018-11-13 11:00:01 -0800 by the following code
has not been returned to the pool:
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot at
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack.fillInStackTrace(ThrowableCallStack.java:71)
at org.apache.tomcat.dbcp.pool2.impl.DefaultPooledObject.allocate(DefaultPooledObject.java:192)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:455)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:361)
at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1543)
at com.sample.test.db.SlaveDBConnection.initiateConnection(SlaveDBConnection.java:40)
at com.sample.test.db.SlaveDBConnection.<init>(SlaveDBConnection.java:25)
at com.sample.test.db.DBFactory.getDBObject(DBFactory.java:80)
at com.sample.test.app.model.dao.UserDAOImpl.getUserData(UserDAOImpl.java:1795)
at org.apache.jsp.getData_jsp._jspService(getData_jsp.java:298)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:443)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.MFilter.doFilter(MFilter.java:52)
Here what is ment by
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot and when
do we get this issue. And how can we reproduce this issue?
tomcat connection-pooling tomcat8.5
edited Nov 19 at 8:37
Selaron
974714
asked Nov 16 at 13:10
Yella Goud
47310
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
How do you release the connection?
– Selaron
Nov 19 at 7:34
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Found following logs sometimes in Tomcat8.5. When we observe error
stacktrace we didn't found any connection leak in the code but the log
is captured for sometimes. I am unable to recognize whether this is
the indication to connection leak or any other issue.
Pooled object created 2018-11-13 11:00:01 -0800 by the following code
has not been returned to the pool:
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot at
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack.fillInStackTrace(ThrowableCallStack.java:71)
at org.apache.tomcat.dbcp.pool2.impl.DefaultPooledObject.allocate(DefaultPooledObject.java:192)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:455)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:361)
at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1543)
at com.sample.test.db.SlaveDBConnection.initiateConnection(SlaveDBConnection.java:40)
at com.sample.test.db.SlaveDBConnection.<init>(SlaveDBConnection.java:25)
at com.sample.test.db.DBFactory.getDBObject(DBFactory.java:80)
at com.sample.test.app.model.dao.UserDAOImpl.getUserData(UserDAOImpl.java:1795)
at org.apache.jsp.getData_jsp._jspService(getData_jsp.java:298)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:443)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.MFilter.doFilter(MFilter.java:52)
Here what is ment by
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot and when
do we get this issue. And how can we reproduce this issue?
tomcat connection-pooling tomcat8.5
edited Nov 19 at 8:37
Selaron
974714
asked Nov 16 at 13:10
Yella Goud
47310
Found following logs sometimes in Tomcat8.5. When we observe error
stacktrace we didn't found any connection leak in the code but the log
is captured for sometimes. I am unable to recognize whether this is
the indication to connection leak or any other issue.
Pooled object created 2018-11-13 11:00:01 -0800 by the following code
has not been returned to the pool:
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot at
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack.fillInStackTrace(ThrowableCallStack.java:71)
at org.apache.tomcat.dbcp.pool2.impl.DefaultPooledObject.allocate(DefaultPooledObject.java:192)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:455)
at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:361)
at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1543)
at com.sample.test.db.SlaveDBConnection.initiateConnection(SlaveDBConnection.java:40)
at com.sample.test.db.SlaveDBConnection.<init>(SlaveDBConnection.java:25)
at com.sample.test.db.DBFactory.getDBObject(DBFactory.java:80)
at com.sample.test.app.model.dao.UserDAOImpl.getUserData(UserDAOImpl.java:1795)
at org.apache.jsp.getData_jsp._jspService(getData_jsp.java:298)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:443)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.MFilter.doFilter(MFilter.java:52)
Here what is ment by
org.apache.tomcat.dbcp.pool2.impl.ThrowableCallStack$Snapshot and when
do we get this issue. And how can we reproduce this issue?
tomcat connection-pooling tomcat8.5
tomcat connection-pooling tomcat8.5
edited Nov 19 at 8:37
Selaron
974714
asked Nov 16 at 13:10
Yella Goud
47310
edited Nov 19 at 8:37
Selaron
974714
asked Nov 16 at 13:10
Yella Goud
47310
edited Nov 19 at 8:37
Selaron
974714
edited Nov 19 at 8:37
Selaron
974714
edited Nov 19 at 8:37
Selaron
974714
974714
asked Nov 16 at 13:10
Yella Goud
47310
asked Nov 16 at 13:10
Yella Goud
47310
asked Nov 16 at 13:10
Yella Goud
47310
47310
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
How do you release the connection?
– Selaron
Nov 19 at 7:34
add a comment |
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
How do you release the connection?
– Selaron
Nov 19 at 7:34
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
How do you release the connection?
– Selaron
Nov 19 at 7:34
How do you release the connection?
– Selaron
Nov 19 at 7:34
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
The web application you are running has logAbandoned flag activated for the resource pool. Whenever the app acquires a new JDBC connection, the Pool will take the (overhead) time and record the call stack trace in memory.
Whenever it later on recognices that a JDBC conection had not been closed properly, it will take that stack trace snapshot and dump it into the log, pointing to the exact location (Java source file and line if compiled for debug) where the connection was acquired which had not been closed safely, taking the risk of connection leaks.
The reproducability strongly depends on what and when the application is actually doing. It might be hard to reproduce if there are several side conditions for this to occoure, but you can read the actual location from where it happens in the stack trace and possibly analyze the source code, find the guilty lines of code and maybe even blame the developer ;-)
See the Tomcat documentation for further reading here.
answered Nov 16 at 13:44
Selaron
974714
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The web application you are running has logAbandoned flag activated for the resource pool. Whenever the app acquires a new JDBC connection, the Pool will take the (overhead) time and record the call stack trace in memory.
Whenever it later on recognices that a JDBC conection had not been closed properly, it will take that stack trace snapshot and dump it into the log, pointing to the exact location (Java source file and line if compiled for debug) where the connection was acquired which had not been closed safely, taking the risk of connection leaks.
The reproducability strongly depends on what and when the application is actually doing. It might be hard to reproduce if there are several side conditions for this to occoure, but you can read the actual location from where it happens in the stack trace and possibly analyze the source code, find the guilty lines of code and maybe even blame the developer ;-)
See the Tomcat documentation for further reading here.
answered Nov 16 at 13:44
Selaron
974714
add a comment |
up vote
1
down vote
The web application you are running has logAbandoned flag activated for the resource pool. Whenever the app acquires a new JDBC connection, the Pool will take the (overhead) time and record the call stack trace in memory.
Whenever it later on recognices that a JDBC conection had not been closed properly, it will take that stack trace snapshot and dump it into the log, pointing to the exact location (Java source file and line if compiled for debug) where the connection was acquired which had not been closed safely, taking the risk of connection leaks.
The reproducability strongly depends on what and when the application is actually doing. It might be hard to reproduce if there are several side conditions for this to occoure, but you can read the actual location from where it happens in the stack trace and possibly analyze the source code, find the guilty lines of code and maybe even blame the developer ;-)
See the Tomcat documentation for further reading here.
answered Nov 16 at 13:44
Selaron
974714
add a comment |
up vote
1
down vote
up vote
1
down vote
The web application you are running has logAbandoned flag activated for the resource pool. Whenever the app acquires a new JDBC connection, the Pool will take the (overhead) time and record the call stack trace in memory.
Whenever it later on recognices that a JDBC conection had not been closed properly, it will take that stack trace snapshot and dump it into the log, pointing to the exact location (Java source file and line if compiled for debug) where the connection was acquired which had not been closed safely, taking the risk of connection leaks.
The reproducability strongly depends on what and when the application is actually doing. It might be hard to reproduce if there are several side conditions for this to occoure, but you can read the actual location from where it happens in the stack trace and possibly analyze the source code, find the guilty lines of code and maybe even blame the developer ;-)
See the Tomcat documentation for further reading here.
answered Nov 16 at 13:44
Selaron
974714
The web application you are running has logAbandoned flag activated for the resource pool. Whenever the app acquires a new JDBC connection, the Pool will take the (overhead) time and record the call stack trace in memory.
Whenever it later on recognices that a JDBC conection had not been closed properly, it will take that stack trace snapshot and dump it into the log, pointing to the exact location (Java source file and line if compiled for debug) where the connection was acquired which had not been closed safely, taking the risk of connection leaks.
The reproducability strongly depends on what and when the application is actually doing. It might be hard to reproduce if there are several side conditions for this to occoure, but you can read the actual location from where it happens in the stack trace and possibly analyze the source code, find the guilty lines of code and maybe even blame the developer ;-)
See the Tomcat documentation for further reading here.
answered Nov 16 at 13:44
Selaron
974714
answered Nov 16 at 13:44
Selaron
974714
answered Nov 16 at 13:44
Selaron
974714
answered Nov 16 at 13:44
Selaron
974714
974714
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53338598%2ftomcat-connection-pool-throwablecallstack-issue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The ThreadCallStack#Snapshot does not mean anything on its own - it just gives the stack trace occurrence in the log file a name in this case. The name tries to be self explaining and want's to say: this is not an actual Exception but a snapshot of a call stack trace. I gues you did not add the entire stack trace. please add the full stack trace which will tell you where a JDBC connection has been acquired which has not properly been closed.
– Selaron
Nov 16 at 13:37
@Selaron Please check now added complete stack trace. In getUserData() method, connection is released properly but I didn't post the code. Is there any possibility if connection is not closed properly in some other method and calling for connection in getUserData() will give above log???
– Yella Goud
Nov 16 at 17:11
How do you release the connection?
– Selaron
Nov 19 at 7:34