Bug 753746

Summary: "Duplicate attempt to close session...", startup error is found with jboss-brms.war.
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Ryan Zhang <rzhang>
Component: BRM (Guvnor)Assignee: manstis
Status: VERIFIED --- QA Contact: Jiri Locker <jlocker>
Severity: low Docs Contact:
Priority: low    
Version: BRMS 5.3.0.GACC: mproctor
Target Milestone: ---   
Target Release: BRMS 5.3.0.GA   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
server.log none

Description Ryan Zhang 2011-11-14 11:22:43 UTC 
Description of problem:


Version-Release number of selected component (if applicable):
BRMS 5.3.0.DEV5


How reproducible:
Startup jboss brms standanlone 5.3.0.DEV5, the error can be seen in server.log。 

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Ryan Zhang 2011-11-16 06:36:23 UTC 
Created attachment 533912 [details]
server.log
Comment 2 Ryan Zhang 2011-11-16 06:36:55 UTC 
Error log shows the following: 

2011-11-14 11:31:48,038 WARN  [org.apache.jackrabbit.core.session.SessionState] (Finalizer) Attempt to close session-guest-6 after it has already been closed. Please review your code for proper session management.
java.lang.Exception: Stack trace of the duplicate attempt to close session-guest-6
	at org.apache.jackrabbit.core.session.SessionState.close(SessionState.java:250)
	at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:888)
	at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:389)
	at org.drools.repository.RulesRepository.logout(RulesRepository.java:198)
	at org.drools.repository.RulesRepository.finalize(RulesRepository.java:1868)
	at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
	at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
	at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
2011-11-14 11:31:48,039 WARN  [org.apache.jackrabbit.core.session.SessionState] (Finalizer) session-guest-6 has already been closed. See the attached exception for a trace of where this session was closed.
java.lang.Exception: Stack trace of  where session-guest-6 was originally closed
	at org.apache.jackrabbit.core.session.SessionState.close(SessionState.java:245)
	at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:888)
	at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:389)
	at org.drools.repository.RulesRepository.logout(RulesRepository.java:198)
	at org.drools.guvnor.server.repository.RulesRepositoryManager.close(RulesRepositoryManager.java:67)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
	at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
	at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
	at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
	at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
	at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
	at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
	at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
	at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
	at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
	at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
	at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
	at org.drools.guvnor.server.repository.RulesRepositoryManager_$$_javassist_seam_5.close(RulesRepositoryManager_$$_javassist_seam_5.java)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
	at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
	at org.jboss.seam.Component.callComponentMethod(Component.java:2275)
	at org.jboss.seam.Component.callDestroyMethod(Component.java:2206)
	at org.jboss.seam.Component.destroy(Component.java:1472)
	at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:252)
	at org.jboss.seam.contexts.Contexts.flushAndDestroyContexts(Contexts.java:413)
	at org.jboss.seam.contexts.ServletLifecycle.endRequest(ServletLifecycle.java:84)
	at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:74)
	at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
	at java.lang.Thread.run(Thread.java:662)
Comment 3 Geoffrey De Smet 2012-01-24 15:48:04 UTC 
The lifecycle in 5.3 and earlier of RulesRepository is fishy at best. The 5.4 seam-weld upgrade fixes this thoroughly.

Meanwhile, in 5.3 the logout() method is called more then it should (including probably RulesRepository.finalize() and FileManagerUtils.destroy()), so I 've gone for the safest workaround: only log out the first time it is called.

https://github.com/droolsjbpm/guvnor/commit/4e0873f8dcf53f812dd7929c59c7767b61ea8777
Comment 4 Ryan Zhang 2012-02-15 09:11:41 UTC 
Please verify the issue on 5.3 ER4.
Comment 5 Ryan Zhang 2012-03-23 07:52:02 UTC 
This issue has been partially fixed. But I think it solves the main problem. It won't reports  session already close error endlessly.
However duplcate session close error stacktrace would still  happen when I shutdown the brms server.

The error stacktrace happening in the shutdown phase is the same as you can see in the server.log attached before. 

Assign back to develop team to have a further look.

Thanks!
Comment 6 Geoffrey De Smet 2012-03-28 13:53:46 UTC 
Since is solves the main problem and the lifecycle itself has been fixed on master for 5.4, does the high/urgent priority still apply to this issue?
Comment 7 Jiri Locker 2012-03-28 15:50:58 UTC 
Geoffrey, see my comment on your commit https://github.com/droolsjbpm/guvnor/commit/4e0873f8dcf53f812dd7929c59c7767b61ea8777#commitcomment-1016487. If the fix is not that easy, then I think it is OK to ignore the errors during shutdown. I don't think it is worth putting much effort in fixing those.
Comment 8 Geoffrey De Smet 2012-03-28 16:08:41 UTC 
The fix is not easy AFAIK, it's basically rewriting the whole lifecycle, which the seam-weld improvements for 5.4 did on master :)
Comment 9 Ryan Zhang 2012-03-29 02:58:52 UTC 
OK， I think it 's fine. Thanks for clarify.
I would low the priority and mark resolved before confirm with QE.