If anyone's interested, we solved this by logging the users out in a
servlet - the error is still there in the error logs, but since we
move the user out of JSF, the user never sees it.
On Thu, Mar 10, 2011 at 15:13, Vetle Roeim <vetler_at_gmail.com> wrote:
> Hi,
>
> After upgrading to Glassfish 3.1, our code for logging out users seem
> to cause problems. It tries to log out users by invalidating the
> session and redirecting the user to another page (using
> ExternalContext.redirect).
>
> Whenever there is an active conversation, and we try to log out users,
> we get the following stack traces, edited for brevity:
>
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$EntryIterator.next(HashMap.java:834)
> at java.util.HashMap$EntryIterator.next(HashMap.java:832)
> at org.jboss.weld.context.AbstractConversationContext.deactivate(AbstractConversationContext.java:250)
> at org.jboss.weld.jsf.WeldPhaseListener.deactivateConversations(WeldPhaseListener.java:131)
> at org.jboss.weld.jsf.WeldPhaseListener.afterPhase(WeldPhaseListener.java:96)
> at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
> ... 54 more
> java.lang.IllegalStateException: Context is not active
> at org.jboss.weld.context.AbstractConversationContext.deactivate(AbstractConversationContext.java:263)
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:125)
> at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4588)
> at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:243)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:328)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
> at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
> at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
> at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
> at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
> at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
> at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
> at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
> at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
> at java.lang.Thread.run(Thread.java:662)
>
> Any ideas about what could cause this?
> I found this WELD bug that seems like a likely culprit:
> https://issues.jboss.org/browse/WELD-833
>
> Regards,
> Vetle
>
--
Vetle Roeim