Found at least a partial explanation. The servlet spec indeed does not mandate that sessionDestroyed gets fired on undeploy or shutdown. Instead tomcat serializes the sessions away to a file and reads it again if you start up the application again. This is indeed a cool feature for 24/7 support as you can ‚ripple-start‘ your application via a round-robin project upgrade (shutdown node 1, redeploy next version of your app, restart node 1, then the same with node 2, etc). So the current behaviour of TomEE is fine and and backed by the spec. I reported CDITCK-482.
LieGrue, strub > Am 16.05.2015 um 18:05 schrieb Romain Manni-Bucau <[email protected]>: > > will connect on IRC now but this was working for sure since I fixed it > twice working on TCKs > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-05-16 18:04 GMT+02:00 Mark Struberg <[email protected]>: > >> Btw this TCK test also blurps up in master, but weirdly it seems to pass: >> >> INFO: Invoke >> SessionContextAsyncListenerTest.testSessionContextActiveOnError: 273/1,494 >> (124) >> May 15, 2015 2:03:56 PM com.gargoylesoftware.htmlunit.WebClient >> printContentIfNecessary >> INFO: statusCode=[500] contentType=[text/html] >> SEVERE - ERROR_0013 >> java.lang.IllegalStateException: Cannot create a session after the >> response has been committed >> at >> org.apache.catalina.connector.Request.doGetSession(Request.java:2877) >> at >> org.apache.catalina.connector.Request.getSession(Request.java:2254) >> at >> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:895) >> at >> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:907) >> at >> org.apache.openejb.cdi.CdiAppContextsService.lazyStartSessionContext(CdiAppContextsService.java:736) >> at >> org.apache.openejb.cdi.CdiAppContextsService.getSessionContext(CdiAppContextsService.java:680) >> at >> org.apache.openejb.cdi.CdiAppContextsService.getCurrentContext(CdiAppContextsService.java:277) >> at >> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:294) >> at >> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:88) >> at >> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:70) >> at >> org.jboss.cdi.tck.tests.context.session.async.SimpleSessionBean$$OwbNormalScopeProxy0.getId(org/jboss/cdi/tck/tests/context/session/async/SimpleSessionBean.java) >> at >> org.jboss.cdi.tck.tests.context.session.async.SimpleAsyncListener.checkSessionContextAvailability(SimpleAsyncListener.java:99) >> at >> org.jboss.cdi.tck.tests.context.session.async.SimpleAsyncListener.onError(SimpleAsyncListener.java:82) >> at >> org.apache.openejb.server.httpd.WebBeansFilter$AsynContextWrapper$ScopeAwareListener.onError(WebBeansFilter.java:233) >> at >> org.apache.catalina.core.AsyncListenerWrapper.fireOnError(AsyncListenerWrapper.java:45) >> at >> org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:415) >> at >> org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:394) >> at >> org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1709) >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:649) >> at >> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1521) >> at >> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1478)May >> 15, 2015 2:03:56 PM com.gargoylesoftware.htmlunit.WebClient >> printContentIfNecessary >> INFO: <!DOCTYPE html><html><head><title>Apache Tomcat (TomEE)/8.0.22 >> (7.0.0-SNAPSHOT) - Error report</title><style type="text/css">H1 >> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} >> H2 >> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} >> H3 >> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} >> BODY >> {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B >> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} >> P >> {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A >> {color : black;}A.name {color : black;}.line {height: 1px; >> background-color: #525D76; border: none;}</style> </head><body><h1>HTTP >> Status 500 - </h1><div class="line"></div><p><b>type</b> Exception >> report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server >> encountered an internal error that prevented it from fulfilling this >> request.</u></p><p><b>exception</b></p><pre>javax.servlet.ServletException >> >> org.jboss.cdi.tck.tests.context.session.async.FailingServlet.service(FailingServlet.java:38) >> javax.servlet.http.HttpServlet.service(HttpServlet.java:729) >> </pre><p><b>note</b> <u>The full stack trace of the root cause is >> available in the Apache Tomcat (TomEE)/8.0.22 (7.0.0-SNAPSHOT) >> logs.</u></p><hr class="line"><h3>Apache Tomcat (TomEE)/8.0.22 >> (7.0.0-SNAPSHOT)</h3></body></html> >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >> at java.lang.Thread.run(Thread.java:745) >> May 15, 2015 2:03:56 PM >> org.jboss.cdi.tck.impl.testng.ProgressLoggingTestListener beforeInvocation >> INFO: Invoke >> SessionContextAsyncListenerTest.testSessionContextActiveOnStartAsync: >> 274/1,494 (124) >> WARNING - Could NOT lazily initialize session context because NO active >> request context >> May 15, 2015 2:03:56 PM >> org.jboss.cdi.tck.impl.testng.ProgressLoggingTestListener beforeInvocation >> INFO: Invoke >> SessionContextAsyncListenerTest.testSessionContextActiveOnTimeout: >> 275/1,494 (124) >> May 15, 2015 2:03:57 PM org.apache.openejb.client.EventLogger log >> INFO: RemoteInitialContextCreated{providerUri= >> http://localhost:42292/tomee/ejb} >> >> >> The current master also is like a Chameleon. It changes from red to green >> and back in just a mere single build ;) >> Means the outcome is currently pretty weird. We need to review why this >> happens. One of those tests is because of the sleep period of 3s in the TCK >> tests is probably too low to give reliable tests. >> >> Will propagate the stuff to master now. >> >> LieGrue, >> strub >> >> >>> Am 16.05.2015 um 17:52 schrieb Mark Struberg <[email protected]>: >>> >>> debugged this in master as well and it is also broken. >>> I guess we just didn’t detect this as in the old OWB version we simply >> cleaned out all SessionContexts we maintained in a HashMap. >>> But in OWB-1.6.0 we now use the real HttpSession so we fail to clean >> this up properly. >>> >>> With other words: it was broken ever since, but we simply didn’t have a >> test hitting this use case. >>> >>> LieGrue, >>> strub >>> >>>> Am 16.05.2015 um 15:55 schrieb Romain Manni-Bucau < >> [email protected]>: >>>> >>>> Le 16 mai 2015 15:12, "Mark Struberg" <[email protected]> a écrit : >>>>> >>>>> And yet a bit more info. >>>>> >>>>> What happens when an app is undeployed using Arquillian then >>>>> >>>>> 1.) the CDI container (OpenEJBLifecycle implements >>>> ContainerLifecycle#stop) gets shut down. This will also stop the >> contexts >>>> it has access to. That does NOT include SessionContexts anymore… >>>>> >>>> >>>> Why, was the case? With your refactoring you mean? >>>> >>>>> 2.) the webapp gets undeployed from Tomcat. This happens in >>>> TomcatWebAppBuilder#undeploy(final StandardContext standardContext, >> final >>>> Container host). >>>>> Please note that the webapp in question _still_ has the state STARTED. >> By >>>> invoking host.removeChild(standardContext); we just remove the context >>>> information from Tomcat but this seems NOT to properly stop the >> application >>>> it seems! >>>>> >>>> >>>> Dont 100% recall but can be async. Breakpoint in >>>> StandardContext#stopInternal >>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>>> Am 16.05.2015 um 14:42 schrieb Mark Struberg <[email protected]>: >>>>>> >>>>>> when using arquillian that seems not to be the case afaics. >>>>>> >>>>>> openejb Assembler#destroyApplication(final AppInfo appInfo) just looks >>>> up the WebBeansLifecycle from OpenWebBeans and shuts it down. By doing >> this >>>> it will also destroy the various contexts. But this does _not_ destroy >> any >>>> _real_ SessionContexts anymore (but only ’synthetic’ HashMap backed >> ones). >>>> It seems it also doesn’t invoke _any_ >> HttpSessionListener#sessionDestroyed >>>> during undeploy of an arquillian webapp. Thus I assume that the webapp >>>> doesn’t get properly undeployed from Tomcat. But this is not really an >> area >>>> where I’m really good in, so I probably missed something. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>>> Am 16.05.2015 um 13:24 schrieb Romain Manni-Bucau < >>>> [email protected]>: >>>>>>> >>>>>>> Normal undeployment will call tomcat one. Same way as we have to >>>> support >>>>>>> for ears so important to have it working this way. >>>>>>> Le 16 mai 2015 12:40, "Mark Struberg" <[email protected]> a écrit : >>>>>>> >>>>>>>> Just saw that my sentence is very ambiguous. >>>>>>>> Of course the undeploy is perfectly fine IF we just use the standard >>>>>>>> tomcat deploy/undeploy. But we do not cleanly undeploy via >> Arquillian >>>>>>>> (which is used in the TCK). >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>>> Am 16.05.2015 um 11:38 schrieb Mark Struberg <[email protected]>: >>>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> We have 2 TCK tests (of the last 4 failing ones) who test the >>>> undeploy >>>>>>>> scenario. They fail as they rely on a clean undeploy - which we do >>>> not do >>>>>>>> atm it seems. >>>>>>>>> >>>>>>>>> In DeployerEJB we do a clean deploy via WebAppDeployer#deploy(). >> This >>>>>>>> creates the Tomcat Context and starts the webapp. But this seems to >>>> miss an >>>>>>>> undeploy(). The result is that any contextDestroyed servlet Listener >>>> will >>>>>>>> not get triggered. >>>>>>>>> Anything I miss? >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >>
