You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Fabrizio Sitzia <fa...@chem.lu> on 2005/10/25 13:51:24 UTC
ConcurrentModificationException during auth-logout
Hello
I'm using Cocoon's (2.1.7 flavour) authentication framework in my webapps.
The webapps are heavily dynamic: Web requests are dispatched to the flow
controller which - depending on the user's permissions - retrieves the
required data from the database (using Hibernate), then sets the context for
the view, which is finally rendered via JX templates.
Now everything's working reasonably fine: accessing the site anonymously,
logging in, accessing the site with different user roles ...everything, except
for that ludicrous logout!
Because logging out using the auth-logout action works randomly at best:
Sometimes it works right away, but half of the time it bombs off with a
java.util.ConcurrentModificationException. If you go back immediately and hit
the 'logout' link again, then - abracadabra - you will be logged out
successfully.
Occasionally, you get logged out successfully although a
ConcurrentModificationException has been thrown (You notice that if you try to
access a protected resource, which will yield the login page!) That leads me
to believe that the precise moment in time when that exception occurs must be
pretty random as well (while or just before rendering the view!)
The bit in my sitemap which performs the auth-logout is unspectacular:
<map:match pattern="auth/do-logout">
<map:act type="auth-logout">
<map:parameter name="handler" value="rsc_auth"/>
</map:act>
<map:redirect-to uri="/rsc_app/index"/>
</map:match>
I've tried a few variations on the theme, as I initially believed that:
- The <redirect-to> tag might be placed incorrectly (inside or outside the
<map:act> block?)
Depending which posts or which parts of the Cocoon documentation you are
reading, you'll find a lot of different ways for writing such a logout
pipeline. Anyway, all variations I tried behaved in the same, faithful way
(randomly throwing a ConcurrentModificationException during logout)
- There might be a race condition involving the rendering of the dynamic
'index' start page, which checks for authenticated user information in the
session context among other things, and the auth-logout action, which
obviously performs some session and continuations cleanup using a big, heavy
axe!
To exclude any race-conditions that might be caused by the rendering of a
complex view, I've tried to replace the redirect-to tag with a construct which
simply reads a static html page that says 'You've been successfully logged
out':
<!-- logout.xml contains a static html page -->
<map:generate src="logout.xml"/>
<map:serialize type="html"/>
...but as you may guess by now, it made no difference :-/
Looking at the error logs, it appears that the exception is always thrown at
the same spot, during invalidateContinuations()!
Huh?
As far as continuations are concerned, I swear to my grandpa's sandals that
I'm not doing anything unholy with them in my code: The only locations
affecting continuations which I'm aware of are the sitemap's <map:call>
constructs, and the sendPage() / showForm() method invocations in my
flowscript code.
Has anyone out there experienced a similar auth-logout, ehrm, behaviour?
Any ideas?
---- Excerpt from the error log:
ERROR (2005-10-25) 11:44.26:215 [sitemap.handled-errors]
(/rsc_app/auth/do-logout) PoolThread-7/ErrorHandlerHelper:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$KeyIterator.next(HashMap.java:818)
at
org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations(ContinuationsManagerImpl.java:487)
at
org.apache.cocoon.components.flow.ContinuationsManagerImpl.access$100(ContinuationsManagerImpl.java:75)
at
org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound(ContinuationsManagerImpl.java:567)
at
org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:805)
at
org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:621)
at
org.apache.cocoon.environment.http.HttpSession.invalidate(HttpSession.java:239)
at
org.apache.cocoon.webapps.session.components.DefaultSessionManager.terminateSession(DefaultSessionManager.java:141)
at
org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.logout(DefaultAuthenticationManager.java:455)
at
org.apache.cocoon.webapps.authentication.acting.LogoutAction.act(LogoutAction.java:76)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:119)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
at org.apache.cocoon.Cocoon.process(Cocoon.java:608)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:342)
at lu.chem.cocoon.HibernateFilter.doFilter(HibernateFilter.java:48)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
Best regards,
Fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ConcurrentModificationException during auth-logout
Posted by Fabrizio Sitzia <fa...@chem.lu>.
Hello,
I'm replying to my own post from two weeks ago...
No! Not because I'm driving nuts!
And I've not fixed the problem yet!
But I found an ugly workaround, which I'm going to describe here:
Got the idea while studying the 'Authentication Framework Block with Flow'
samples. I replaced the auth-logout action in the sitemap with the following
flow invocation:
<map:match pattern="auth/do-logout">
<map:call function="logout"/>
</map:match>
And the logout function now looks like this:
function logout() {
try {
// Occasionally, the auth_logout() invocation bombs off
// with a java.util.ConcurrentModificationException exception!
// ...always at line 97 in auth.js: cocoon.releaseComponent(authMgr);
//
// We catch it, we log it, and we proceed with the logout as if
// nothing ever happened.
auth_logout ("rsc_auth");
}
catch (e) {
cocoon.log.error (e);
}
cocoon.redirectTo("/rsc_app/index");
}
Well, now the following error message occasionally shows up in the webapp's
error log:
ERROR (2005-11-10) 15:13.56:086 [flow] (/rsc_app/auth/do-logout)
PoolThread-5/NativeJavaMethod: java.util.ConcurrentModificationException
But otherwise, the logout is performed flawlessly.
Out of user's sight,
but still in the developer's mind
Fabrizio
> Hello
>
> I'm using Cocoon's (2.1.7 flavour) authentication framework in my webapps.
>
> The webapps are heavily dynamic: Web requests are dispatched to the flow
> controller which - depending on the user's permissions - retrieves the
> required data from the database (using Hibernate), then sets the context for
> the view, which is finally rendered via JX templates.
>
> Now everything's working reasonably fine: accessing the site anonymously,
> logging in, accessing the site with different user roles ...everything, except
> for that ludicrous logout!
>
> Because logging out using the auth-logout action works randomly at best:
>
> Sometimes it works right away, but half of the time it bombs off with a
> java.util.ConcurrentModificationException. If you go back immediately and hit
> the 'logout' link again, then - abracadabra - you will be logged out
> successfully.
>
> Occasionally, you get logged out successfully although a
> ConcurrentModificationException has been thrown (You notice that if you try to
> access a protected resource, which will yield the login page!) That leads me
> to believe that the precise moment in time when that exception occurs must be
> pretty random as well (while or just before rendering the view!)
>
> The bit in my sitemap which performs the auth-logout is unspectacular:
>
> <map:match pattern="auth/do-logout">
> <map:act type="auth-logout">
> <map:parameter name="handler" value="rsc_auth"/>
> </map:act>
> <map:redirect-to uri="/rsc_app/index"/>
> </map:match>
>
>
> I've tried a few variations on the theme, as I initially believed that:
>
> - The <redirect-to> tag might be placed incorrectly (inside or outside the
> <map:act> block?)
> Depending which posts or which parts of the Cocoon documentation you are
> reading, you'll find a lot of different ways for writing such a logout
> pipeline. Anyway, all variations I tried behaved in the same, faithful way
> (randomly throwing a ConcurrentModificationException during logout)
>
> - There might be a race condition involving the rendering of the dynamic
> 'index' start page, which checks for authenticated user information in the
> session context among other things, and the auth-logout action, which
> obviously performs some session and continuations cleanup using a big, heavy
> axe!
>
>
> To exclude any race-conditions that might be caused by the rendering of a
> complex view, I've tried to replace the redirect-to tag with a construct which
> simply reads a static html page that says 'You've been successfully logged
> out':
>
> <!-- logout.xml contains a static html page -->
> <map:generate src="logout.xml"/>
> <map:serialize type="html"/>
>
> ...but as you may guess by now, it made no difference :-/
>
>
> Looking at the error logs, it appears that the exception is always thrown at
> the same spot, during invalidateContinuations()!
> Huh?
>
> As far as continuations are concerned, I swear to my grandpa's sandals that
> I'm not doing anything unholy with them in my code: The only locations
> affecting continuations which I'm aware of are the sitemap's <map:call>
> constructs, and the sendPage() / showForm() method invocations in my
> flowscript code.
>
>
> Has anyone out there experienced a similar auth-logout, ehrm, behaviour?
> Any ideas?
>
>
> ---- Excerpt from the error log:
>
> ERROR (2005-10-25) 11:44.26:215 [sitemap.handled-errors]
> (/rsc_app/auth/do-logout) PoolThread-7/ErrorHandlerHelper:
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
> at java.util.HashMap$KeyIterator.next(HashMap.java:818)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations(ContinuationsManagerImpl.java:487)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.access$100(ContinuationsManagerImpl.java:75)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound(ContinuationsManagerImpl.java:567)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:805)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:621)
> at
> org.apache.cocoon.environment.http.HttpSession.invalidate(HttpSession.java:239)
> at
> org.apache.cocoon.webapps.session.components.DefaultSessionManager.terminateSession(DefaultSessionManager.java:141)
> at
> org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.logout(DefaultAuthenticationManager.java:455)
> at
> org.apache.cocoon.webapps.authentication.acting.LogoutAction.act(LogoutAction.java:76)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:119)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:608)
> at
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:342)
> at lu.chem.cocoon.HibernateFilter.doFilter(HibernateFilter.java:48)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
> at
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
> at org.mortbay.http.HttpServer.service(HttpServer.java:879)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
> at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
> at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
>
>
> Best regards,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ConcurrentModificationException during auth-logout
Posted by Joerg Heinicke <jo...@gmx.de>.
Forwarding to dev list ...
http://marc.theaimsgroup.com/?t=113024125800002&r=1&w=4
Jörg
On 25.10.2005 13:51, Fabrizio Sitzia wrote:
> Hello
>
> I'm using Cocoon's (2.1.7 flavour) authentication framework in my webapps.
>
> The webapps are heavily dynamic: Web requests are dispatched to the flow
> controller which - depending on the user's permissions - retrieves the
> required data from the database (using Hibernate), then sets the context for
> the view, which is finally rendered via JX templates.
>
> Now everything's working reasonably fine: accessing the site anonymously,
> logging in, accessing the site with different user roles ...everything, except
> for that ludicrous logout!
>
> Because logging out using the auth-logout action works randomly at best:
>
> Sometimes it works right away, but half of the time it bombs off with a
> java.util.ConcurrentModificationException. If you go back immediately and hit
> the 'logout' link again, then - abracadabra - you will be logged out
> successfully.
>
> Occasionally, you get logged out successfully although a
> ConcurrentModificationException has been thrown (You notice that if you try to
> access a protected resource, which will yield the login page!) That leads me
> to believe that the precise moment in time when that exception occurs must be
> pretty random as well (while or just before rendering the view!)
>
> The bit in my sitemap which performs the auth-logout is unspectacular:
>
> <map:match pattern="auth/do-logout">
> <map:act type="auth-logout">
> <map:parameter name="handler" value="rsc_auth"/>
> </map:act>
> <map:redirect-to uri="/rsc_app/index"/>
> </map:match>
>
>
> I've tried a few variations on the theme, as I initially believed that:
>
> - The <redirect-to> tag might be placed incorrectly (inside or outside the
> <map:act> block?)
> Depending which posts or which parts of the Cocoon documentation you are
> reading, you'll find a lot of different ways for writing such a logout
> pipeline. Anyway, all variations I tried behaved in the same, faithful way
> (randomly throwing a ConcurrentModificationException during logout)
>
> - There might be a race condition involving the rendering of the dynamic
> 'index' start page, which checks for authenticated user information in the
> session context among other things, and the auth-logout action, which
> obviously performs some session and continuations cleanup using a big, heavy
> axe!
>
>
> To exclude any race-conditions that might be caused by the rendering of a
> complex view, I've tried to replace the redirect-to tag with a construct which
> simply reads a static html page that says 'You've been successfully logged
> out':
>
> <!-- logout.xml contains a static html page -->
> <map:generate src="logout.xml"/>
> <map:serialize type="html"/>
>
> ...but as you may guess by now, it made no difference :-/
>
>
> Looking at the error logs, it appears that the exception is always thrown at
> the same spot, during invalidateContinuations()!
> Huh?
>
> As far as continuations are concerned, I swear to my grandpa's sandals that
> I'm not doing anything unholy with them in my code: The only locations
> affecting continuations which I'm aware of are the sitemap's <map:call>
> constructs, and the sendPage() / showForm() method invocations in my
> flowscript code.
>
>
> Has anyone out there experienced a similar auth-logout, ehrm, behaviour?
> Any ideas?
>
>
> ---- Excerpt from the error log:
>
> ERROR (2005-10-25) 11:44.26:215 [sitemap.handled-errors]
> (/rsc_app/auth/do-logout) PoolThread-7/ErrorHandlerHelper:
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
> at java.util.HashMap$KeyIterator.next(HashMap.java:818)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations(ContinuationsManagerImpl.java:487)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.access$100(ContinuationsManagerImpl.java:75)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound(ContinuationsManagerImpl.java:567)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:805)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:621)
> at
> org.apache.cocoon.environment.http.HttpSession.invalidate(HttpSession.java:239)
> at
> org.apache.cocoon.webapps.session.components.DefaultSessionManager.terminateSession(DefaultSessionManager.java:141)
> at
> org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.logout(DefaultAuthenticationManager.java:455)
> at
> org.apache.cocoon.webapps.authentication.acting.LogoutAction.act(LogoutAction.java:76)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ConcurrentModificationException during auth-logout
Posted by Joerg Heinicke <jo...@gmx.de>.
Forwarding to dev list ...
http://marc.theaimsgroup.com/?t=113024125800002&r=1&w=4
Jörg
On 25.10.2005 13:51, Fabrizio Sitzia wrote:
> Hello
>
> I'm using Cocoon's (2.1.7 flavour) authentication framework in my webapps.
>
> The webapps are heavily dynamic: Web requests are dispatched to the flow
> controller which - depending on the user's permissions - retrieves the
> required data from the database (using Hibernate), then sets the context for
> the view, which is finally rendered via JX templates.
>
> Now everything's working reasonably fine: accessing the site anonymously,
> logging in, accessing the site with different user roles ...everything, except
> for that ludicrous logout!
>
> Because logging out using the auth-logout action works randomly at best:
>
> Sometimes it works right away, but half of the time it bombs off with a
> java.util.ConcurrentModificationException. If you go back immediately and hit
> the 'logout' link again, then - abracadabra - you will be logged out
> successfully.
>
> Occasionally, you get logged out successfully although a
> ConcurrentModificationException has been thrown (You notice that if you try to
> access a protected resource, which will yield the login page!) That leads me
> to believe that the precise moment in time when that exception occurs must be
> pretty random as well (while or just before rendering the view!)
>
> The bit in my sitemap which performs the auth-logout is unspectacular:
>
> <map:match pattern="auth/do-logout">
> <map:act type="auth-logout">
> <map:parameter name="handler" value="rsc_auth"/>
> </map:act>
> <map:redirect-to uri="/rsc_app/index"/>
> </map:match>
>
>
> I've tried a few variations on the theme, as I initially believed that:
>
> - The <redirect-to> tag might be placed incorrectly (inside or outside the
> <map:act> block?)
> Depending which posts or which parts of the Cocoon documentation you are
> reading, you'll find a lot of different ways for writing such a logout
> pipeline. Anyway, all variations I tried behaved in the same, faithful way
> (randomly throwing a ConcurrentModificationException during logout)
>
> - There might be a race condition involving the rendering of the dynamic
> 'index' start page, which checks for authenticated user information in the
> session context among other things, and the auth-logout action, which
> obviously performs some session and continuations cleanup using a big, heavy
> axe!
>
>
> To exclude any race-conditions that might be caused by the rendering of a
> complex view, I've tried to replace the redirect-to tag with a construct which
> simply reads a static html page that says 'You've been successfully logged
> out':
>
> <!-- logout.xml contains a static html page -->
> <map:generate src="logout.xml"/>
> <map:serialize type="html"/>
>
> ...but as you may guess by now, it made no difference :-/
>
>
> Looking at the error logs, it appears that the exception is always thrown at
> the same spot, during invalidateContinuations()!
> Huh?
>
> As far as continuations are concerned, I swear to my grandpa's sandals that
> I'm not doing anything unholy with them in my code: The only locations
> affecting continuations which I'm aware of are the sitemap's <map:call>
> constructs, and the sendPage() / showForm() method invocations in my
> flowscript code.
>
>
> Has anyone out there experienced a similar auth-logout, ehrm, behaviour?
> Any ideas?
>
>
> ---- Excerpt from the error log:
>
> ERROR (2005-10-25) 11:44.26:215 [sitemap.handled-errors]
> (/rsc_app/auth/do-logout) PoolThread-7/ErrorHandlerHelper:
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
> at java.util.HashMap$KeyIterator.next(HashMap.java:818)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.invalidateContinuations(ContinuationsManagerImpl.java:487)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl.access$100(ContinuationsManagerImpl.java:75)
> at
> org.apache.cocoon.components.flow.ContinuationsManagerImpl$WebContinuationsHolder.valueUnbound(ContinuationsManagerImpl.java:567)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:805)
> at
> org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:621)
> at
> org.apache.cocoon.environment.http.HttpSession.invalidate(HttpSession.java:239)
> at
> org.apache.cocoon.webapps.session.components.DefaultSessionManager.terminateSession(DefaultSessionManager.java:141)
> at
> org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.logout(DefaultAuthenticationManager.java:455)
> at
> org.apache.cocoon.webapps.authentication.acting.LogoutAction.act(LogoutAction.java:76)