You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2012/11/07 23:53:33 UTC
[Bug 54116] New: Deadlocks with mysql driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
Priority: P2
Bug ID: 54116
Assignee: dev@tomcat.apache.org
Summary: Deadlocks with mysql driver
Severity: critical
Classification: Unclassified
OS: Linux
Reporter: casado.alfredo@gmail.com
Hardware: PC
Status: NEW
Version: unspecified
Component: jdbc-pool
Product: Tomcat Modules
Created attachment 29567
--> https://issues.apache.org/bugzilla/attachment.cgi?id=29567&action=edit
stack information with the blockeds threads
The problem is very well detailed in the following mysql bug:
http://bugs.mysql.com/bug.php?id=64954
I found exactly the same situation related in this mysql bug. The answer from
mysql guys is:
"This is precisely the reason the JDBC-4.0 spec added the abort() method. There
is no foolproof way to implement the semantics of Connection.close() *and*
never have deadlocks.
The abort() method is designed to be used in these cases (it takes no locks,
but doesn't attempt to clean up currently open statements, etc).
Have you asked your connection pool vendor why they're not using the abort()
method?"
And the bug's is market with "won't fix". My question is, ¿is jdbc-pool using
this abort method instead of close?, ¿if the "Pool-Cleaner" is one of the
threads involved in the blocking this can cause connections not removed from
the pool?. I attach to this bug the stack trace information, yo can see that
this thread is blocked. I can reproduce this error via load/stress testing the
application, in production this error occurs randomly between 3 or 4 days
running.
For more information i'm using grails with the grails tomcat jdbc plugin
(http://grails.org/plugin/jdbc-pool).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
--- Comment #2 from Alfredo Casado <ca...@gmail.com> ---
Thanks for your response.
Please can you answer my second question: ¿if the Pool-Cleaner thread is
blocked how this affect the behaviour of the pool?, ¿the pool is no longer
"clean" unused connections?. If this is true the problem is really a big issue
in production
environments using tomcat+mysql.
In the first place i go to mysql driver project issue manager, i found one
report of a identical bug and following the recomendations in this issue i'm
here contacting with "my pool vendor". As you can see now i have two deadlocks:
one in my production servers and the second one in this bug resolution.
As you can see in the mysql bug they insist that the pool implementation must
call abort() instead of close(). I'm not sure what are the implications of
this.
I'm not an expert in JDBC spec and in driver's or pool's implementations
details, i can't judge if the problem is in mysql driver like you say or if the
problem is in pool implementations, like the mysql guy say.
I have the following options:
- go again to mysql issue manager and reopen the bug.
- don't use jdbc-pool (i think that others pool implementations call close in
the same way, the option is not using a pool at all)
- don't use mysql j/connector driver. ¿is there another mysql driver
implementation i can use?
¿what do you recomend?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
--- Comment #1 from Patric Rufflar <pa...@rufflar.com> ---
Looks like mysql jdbc driver bug because they use inconsistent locking:
com.mysql.jdbc.ConnectionImpl.close() locks in the following order:
1. com.mysql.jdbc.JDBC4Connection
2. com.mysql.jdbc.JDBC4ResultSet
while com.mysql.jdbc.ResultSetImpl.getString() locks in a reversed order:
1. com.mysql.jdbc.JDBC4ResultSet
2. com.mysql.jdbc.JDBC4Connection
Because I see no jdbc pool classes involved in the locking of these objects I
doubt that jdbc pool is responsible in this deadlock situation.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Mark Thomas <ma...@apache.org> ---
Inconsistent locking in the driver is not a JDBC pool issue.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
--- Comment #3 from Patric Rufflar <pa...@rufflar.com> ---
The pool cleaner thread periodically
- checks for abandoned connections (depending on configuration)
- does pool resizing (e.g. dropping connections), if necessary
- verifies idle connections (depending on configuration)
If this thread gets blocked you'll loose this functionality.
It depends on your application if you rely on these features or not.
Normally, this will not cause your application to fail (completely).
If I were you I would drop a comment at the existing mysql issue and tell them
that they use inconsistent locking in their jdbc driver which is causing the
problem here.
Also mention that Connection.abort() is only available in java 7.
If they will not fix the inconsistent locking ask for a java 6 compatible
solution.
BTW: A workaround which will lower the probability of the deadlock is to
disable the jdbc-pool's "remove abandoned connections" feature.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org