[Hibernate-JIRA] Created: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
1:41 a.m.
ConcurrentModificationException in AbstractBatcher results in infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:15 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Gail Badner commented on HHH-3006:
----------------------------------
Please attach a runnable test case (Java + mappings) that reproduce this issue.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.4, 3.2.4.sp1, 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Stefan Hauk updated HHH-3006:
-----------------------------
Attachment: batcherinfinitelooptest.zip
Attached a JUnit test case (requires JMock2, included in ZIP). Note that this test will
run into an infinite loop if the bug is present!
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.4, 3.2.4.sp1, 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Attachments: batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:58 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Stefan Hauk updated HHH-3006:
-----------------------------
Attachment: batcherinfinitelooptest.zip
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.4, 3.2.4.sp1, 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:33 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Paul Smith commented on HHH-3006:
---------------------------------
We've managed to hit this one this evening. Causes a LOT of logging let me tell you!
We get this:
[2008-02-12 11:32:06,973 WARN ][jdbc.AbstractBatcher][http-2001-Processor128 ][][] Could
not close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:280)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:208)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
com.aconex.servlet.SessionValidationFilter.doFilterInternal(SessionValidationFilter.java:130)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
com.aconex.security.controller.RequestCookieFilter.doFilterInternal(RequestCookieFilter.java:22)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
over and over again, So much so it caused the system cpu time to hit 20% on a Linux
system.
this pretty much killed our production system. It's the first time we've seen
this, so it has to be rare, but when it happens it's pretty impressive. we're
running 3.2.4sp1.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3, 3.2.4, 3.2.4.sp1, 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:45 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Steve Ebersole commented on HHH-3006:
-------------------------------------
The attached test case uses a separate thread to achieve this concurrent modification
problem. In "real life" this would mean you would have to have 2 (or more)
threads simultaneously accessing the same session. That is explicitly disallowed.
Can you reproduce this error w/o resorting to separate threads?
If this is something which happens simply because there is actually a concurrent
modification scenario with multiple threads accessing the same collection, then there is
nothing to fix (aside from the the code which accesses the same session from multiple
concurrent threads).
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:45 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Steve Ebersole updated HHH-3006:
--------------------------------
Assignee: Steve Ebersole
Affects Version/s: (was: 3.2.4.sp1)
(was: 3.2.4)
(was: 3.2.3)
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:46 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Kariem Hussein commented on HHH-3006:
-------------------------------------
I have observed a similar problem on Websphere. I cannot really see the cause, because the
logs fill up too fast, and you cannot really stop a running production service or get the
right log file in time (rotating log files). We are trying to reproduce the error, but it
only happened once after running for ten days with 3.2.5. We did not encounter this error
using an older version for more than 13 months.
At the moment I don't really have an idea why this is happens, but our application
uses the same design as Stefan's or Paul's applications.
Here my stacktrace:
WebContainer : 3 org.hibernate.jdbc.AbstractBatcher - Could not close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:842)
at java.util.HashMap$KeyIterator.next(HashMap.java:878)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at
org.hibernate.jdbc.ConnectionManager.manualDisconnect(ConnectionManager.java:339)
at org.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:375)
at
at.buak.erueck.web.filter.HibernateSession.disconnectSession(HibernateSession.java:81)
at
at.buak.erueck.web.filter.HibernateSession.doTransactionCommit(HibernateSession.java:126)
at
at.buak.erueck.web.filter.HibernateSessionFilter.doFilterInternal(HibernateSessionFilter.java:81)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:761)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:673)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:498)
at
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:464)
at
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:96)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:163)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
Currently I don't see a reason for the concurrent modification exception. The filter
should only be called once per request (from one thread) and use a unique session per
request.
I believe the problem here is not what causes this error, but rather how the error is
handled. Could you catch NPE instead of Throwable in line 320? This should be sufficient
for Sybase, right? It would also help with the investigation of the cause.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:12 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Marcus popetz commented on HHH-3006:
------------------------------------
We run into this in jboss when the background reaper tries to cancel the transaction after
a timeout. (only in rare cases where we lost database connectivity for other reasons so
it's hard for me to produce a test case as well).
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at
org.hibernate.jdbc.ConnectionManager.afterTransaction(ConnectionManager.java:297)
at
org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:221)
at
org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:340)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:107)
at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:230)
at
com.arjuna.ats.arjuna.coordinator.TransactionReaper.check(TransactionReaper.java:202)
at
com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:107)
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:40 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Denis Forveille commented on HHH-3006:
--------------------------------------
+1
Happens when the application is under stress
We don't have a way to reproduce it for sure.
Maybe it's the way Seam uses the hibernate session...or the way we use Seam. For us it
seem very hard to debug and create a scenario to reproduce the bug
Hibernate v3.2.5
Seam v1.2.1
WebSphere v6.1.0.13
DB2 v8.2.8
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:57 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Remi Gerbaud commented on HHH-3006:
-----------------------------------
We got the same problem with 3.2.6ga, tomcat 5.5 and MySQL 5.0.51-3.
But this problem comes once per day... We must restart tomcat to stop the increase of the
log size...
We got this problem since we put 3.2.6 instead of 3.2.2, and we don't find any fix, so
if someone have an idea, we can try it.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:22 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Kariem Hussein commented on HHH-3006:
-------------------------------------
I might be wrong, but I think the problem is that the Throwable should not be catched.
Instead a null pointer exception would be sufficient according to the comment. Or am i
totally wrong on that? According to SVN this change was introduced in 3.2.3, which would
match Remi's observation. We upgraded from a 3.1.x version.
3.2.2:
http://anonsvn.jboss.org/repos/hibernate/core/tags/v322/src/org/hibernate...
3.2.3 - 3.2.6
http://anonsvn.jboss.org/repos/hibernate/core/tags/v323/src/org/hibernate...
http://anonsvn.jboss.org/repos/hibernate/core/tags/v324/src/org/hibernate...
http://anonsvn.jboss.org/repos/hibernate/core/tags/v325/src/org/hibernate...
http://anonsvn.jboss.org/repos/hibernate/core/tags/v326/src/org/hibernate...
Sorry, no links from fisheye: I could not find a URL with nice annotations.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:28 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
John Mazzitelli commented on HHH-3006:
--------------------------------------
I can say it is not related to Seam's usage of hibernate. Just hit this with my JPA
app (no Seam involved) going against Oracle 10g with hibernate v3.2.6+ (its actually a
build from revision 14201) - and yes, app was under severe load:
Here's the log with stack in case its important:
2008-03-14 15:16:38,750 WARN [org.hibernate.jdbc.AbstractBatcher] Could not close a JDBC
result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at org.hibernate.ejb.EntityManagerImpl.close(EntityManagerImpl.java:86)
at
org.jboss.ejb3.entity.ManagedEntityManagerFactory$SessionSynchronization.afterCompletion(ManagedEntityManagerFactory.java:129)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:340)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:107)
at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:230)
at com.arjuna.ats.arjuna.coordinator.TransactionReaper.check(TransactionReaper.java:198)
at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:107)
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Andy Peel commented on HHH-3006:
--------------------------------
We also have had this issue, occuring for the 2nd time today, the first time 4 months ago.
It knocked out our production system having filled the disk with 100 GB of log.
Possibly it occurred due to a transaction timeout, as someone found above - we suffer a
lot from these.
We're using JBoss 4.2.0 (Hibernate 3.2.3.ga).
Our stack trace:
2008-04-23 09:23:12,451 WARN [Thread-10] AbstractBatcher | Could not close a JDBC result
set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at org.hibernate.ejb.EntityManagerImpl.close(EntityManagerImpl.java:86)
at
org.jboss.ejb3.entity.ManagedEntityManagerFactory$SessionSynchronization.afterCompletion(ManagedEntityManagerFactory.java:129)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:342)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:109)
at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:230)
at
com.arjuna.ats.arjuna.coordinator.TransactionReaper.check(TransactionReaper.java:198)
at
com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:107)
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:48 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Brent Falk commented on HHH-3006:
---------------------------------
We are experiencing the same issue. Stack trace is as follows:
2008-04-23 16:22:16,044 WARN [org.hibernate.jdbc.AbstractBatcher] Could not close a JDBC
result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at
org.hibernate.jdbc.ConnectionManager.manualDisconnect(ConnectionManager.java:339)
at org.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:375)
at
org.springframework.orm.hibernate3.HibernateTransactionManager.doCleanupAfterCompletion(HibernateTransactionManager.java:669)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager.java:919)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:712)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy54.findPastDueScheduledVisits(Unknown Source)
at sun.reflect.GeneratedMethodAccessor892.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:304)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:139)
at
org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy55.findPastDueScheduledVisits(Unknown Source)
at
com.napadex.web.electives.ScheduleElectivePrepareAction.executeElectiveAction(ScheduleElectivePrepareAction.java:26)
at
com.napadex.web.electives.ElectiveBaseAction.executeAction(ElectiveBaseAction.java:38)
at com.napadex.web.global.BaseAction.execute(BaseAction.java:142)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
ca.mb.sbgh.checkpoint.filters.UserPrincipalFilter.doFilter(UserPrincipalFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:392)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
Environment is Jboss 4.0.3SP1, Hibernate 3.2.5ga and Oracle9i.
As was the case with the other commenters, this process got stuck in an infinite loop and
ended up filling the disk partition with log files, also knocking out our application
server. This has only happened twice in 2008 in our production environment, however it
is quite disruptive. It would be much appreciated if the Hibernate AbstractBatcher code
could at least be changed so that it would not log infinitely. Thanks.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:23 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Steve Ebersole commented on HHH-3006:
-------------------------------------
Just heard from some JTA folks. Apparently this can be an issue due to transaction
timeouts depending on how the TM implements timeout "reaping". JBossTM, for
example, will reap timed out transaction in a background thread.
So the simple fix here would be to account explicitly for CME in these 2 cleanups and just
break from the corresponding loops in the case of CME. Since we are explicitly handling
this condition for the case of JTA, we can assume that the DataSource will handle any
resource releasing...
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.x, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:23 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Steve Ebersole updated HHH-3006:
--------------------------------
Fix Version/s: 3.3.0.CR2
3.2.x
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.x, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:47 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Steve Ebersole resolved HHH-3006.
---------------------------------
Resolution: Fixed
committed to both trunk and 3.2 branch.
I understand the difficulty, but if anyone could verify this fix, that would be
fantastic.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.x, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:51 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Buddha Buddy commented on HHH-3006:
-----------------------------------
I feel that the Priority is incorrect for this bug. "Minor loss of function, or other
problem where easy workaround is present" hardly seems to apply to "My
application randomly comes to a screeching halt after filling up the hard drive," and
I've seen no workaround mentioned.
Version 3.2.x means the next release of 3.2, so this fix is not available for 3.2 users,
correct? Is there even a new 3.2 release planned? What is the resolution for 3.2 users?
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.x, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Manish commented on HHH-3006:
-----------------------------
Any one know whats the work around for this?
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.7, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:35 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=c...
]
Chris Wash commented on HHH-3006:
---------------------------------
We saw this today, running 3.2.4.SP1 with MS SQL Server 2007
FYI, for those on JBoss you can use the Log4jService MBean to set the logging level on
org.hibernate.jdbc.AbstractBatcher to ERROR - this should stop with the excessive logging
(which is WARN level).
Currently the thread is still stuck - I haven't found a way to kill an individual
thread (though it's quite easy to ID) using JBoss 4.2 -- If I can find out how I will
post it here.
ConcurrentModificationException in AbstractBatcher results in
infinite loop
---------------------------------------------------------------------------
Key: HHH-3006
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga
MySQL 5.0.42
Reporter: Stefan Hauk
Assignee: Steve Ebersole
Priority: Minor
Fix For: 3.2.7, 3.3.0.CR2
Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip
Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements()
method:
Iterator iter = resultSetsToClose.iterator();
while ( iter.hasNext() ) {
try {
logCloseResults();
( (ResultSet) iter.next() ).close();
}
catch (SQLException e) {
// no big deal
log.warn("Could not close a JDBC result set", e);
}
catch (Throwable e) {
// sybase driver (jConnect) throwing NPE here in certain cases
log.warn("Could not close a JDBC result set", e);
}
}
resultSetsToClose.clear();
In case there is a ConcurrentModificationException thrown when iterating over the
resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause.
However, the iteration may continue infinitely because of the corrupted HashSet. This pegs
one CPU and logs the following stack trace over and over again:
28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not
close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)
at
org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492)
at com.caucho.util.ThreadPool.run(ThreadPool.java:425)
at java.lang.Thread.run(Thread.java:595)
The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly.
Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching
Throwable catches more than that and produces this side-effect.
Now I do realize that the ConcurrentModificationException might be caused by not using
Hibernate in a correct way, but I haven't determined the cause for it yet. However, I
do think that Hibernate should fail more gracefully than it currently does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5028
days inactive
6008
days old
hibernate-issues@lists.jboss.org
20 comments
14 participants
participants (14)
-
Andy Peel (JIRA) -
Brent Falk (JIRA)
-
Buddha Buddy (JIRA)
-
Chris Wash (JIRA)
-
Denis Forveille (JIRA)
-
Gail Badner (JIRA)
-
John Mazzitelli (JIRA)
-
Kariem Hussein (JIRA)
-
Manish (JIRA)
-
Marcus popetz (JIRA)
-
Paul Smith (JIRA)
-
Remi Gerbaud (JIRA)
-
Stefan Hauk (JIRA)
-
Steve Ebersole (JIRA)