[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop

Paul Smith (JIRA) noreply at atlassian.com
Tue Feb 12 07:33:34 EST 2008


    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29502 ] 

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the hibernate-issues mailing list