[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop
Kariem Hussein (JIRA)
noreply at atlassian.com
Tue Feb 19 09:46:33 EST 2008
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29544 ]
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list