Correction, this did *not* fix the issue. Seems like there is no way
around this.
I reported a bug (
http://java.net/jira/browse/GLASSFISH-16234), and
hope someone can get this fixed. I hate screaming about important
bugs, but this one is pretty bad.
The consequence is that whenever a session is invalidated and
conversations cleaned up, the user has to clear cookies to be able to
continue.
On Mon, Mar 14, 2011 at 21:33, Vetle Roeim <vetler_at_gmail.com> wrote:
> 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
>
--
Vetle Roeim