4:48 p.m.
[
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