12:03 a.m.
[
https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin....
]
Sean Flanigan commented on WFLY-3529:
-------------------------------------
By the way, using the latest undertow-core-1.0.16.Final-SNAPSHOT.jar (built from the 1.0.x
branch) doesn't help either, so the fix for WFLY-3385 doesn't help.
This seems to be the sequence of events which leads to the exception:
1. LogoutServlet outputs a redirect to "/HelloWorld", then calls
SessionImpl.invalidate(), but the synchronized method invalidate() takes a while to run
(in this case, because of a slow SessionListener). Until it finishes, the session
won't be removed from the ConcurrentHashMap.
2. The browser receives the redirect, and fetches "/HelloWorld"; the server sees
a valid Session, and hangs on to it for the duration of the request. It then calls
SessionImpl.getAttribute, which calls the synchronized method bumpTimeout(). Note:
because of the synchronization, this blocks until invalidate() finishes. This does depend
on invalidate() being relatively slow, and the network being relatively fast.
3. When invalidate() finally finishes, it calls sessionManager.sessions.remove() and
returns, then bumpTimeout() wakes up and calls getMaxInactiveInterval(): it in turn calls
sessionManager.sessions.get(), but by now the session has been removed from the
ConcurrentHashMap, so it throws IllegalStateException.
The key trigger is that the LogoutServlet redirects before invalidate, which leads to a
race condition between the logout request and the next request. The workaround (fix?) is
for the application to invalidate before redirecting.
It's a bad idea to redirect before invalidate and perhaps illegal, but even so, it
probably shouldn't lead to an ugly exception for the next request. I think any
long-running request could run into a situation where something else invalidates its
session between the start of request processing and the end.
UT000010: Session not found
----------------------------
Key: WFLY-3529
URL: https://issues.jboss.org/browse/WFLY-3529
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web (Undertow)
Environment: Wildfly 8.1.0.Final ,
Reporter: Youssef BIKHCHICHE
Assignee: Stuart Douglas
Attachments: WFLY-3529.tar.gz, WFLY-3529.war
After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has
been fixed in the previous release of wildfly.
ERREOR code :
2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request
failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}:
java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found
cX6YRwOmoXcB8FFUdNY2r7Te
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311)
at
io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128)
at
io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.IllegalStateException: UT000010: Session not found
cX6YRwOmoXcB8FFUdNY2r7Te
at
io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319)
at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121)
at
org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144)
at
org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402)
======================================================
this issue happens after a http session invalidate action and it' not a regular
problems.
Best regards,
Youssef
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
4081
days inactive
4081
days old
0 comments
1 participants
participants (1)
-
Sean Flanigan (JIRA)