[JBoss JIRA] (WFCORE-67) CLI shutting down a slave disconnects from the master
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-67?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFCORE-67:
------------------------------------
Fix Version/s: 1.0.0.Alpha6
> CLI shutting down a slave disconnects from the master
> -----------------------------------------------------
>
> Key: WFCORE-67
> URL: https://issues.jboss.org/browse/WFCORE-67
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 1.0.0.Alpha4
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 1.0.0.Alpha6
>
>
> If I issue a shutdown command for a slave HC, the CLI gets disconnected:
> [domain@localhost:9999 /] shutdown --host=slave-a
> [disconnected /] shutdown --host=slave-b
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [disconnected /] cd /
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [disconnected /] connect
> [domain@localhost:9999 /] shutdown --host=slave-b
> [disconnected /]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFCORE-67) CLI shutting down a slave disconnects from the master
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-67?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFCORE-67.
-------------------------------------
Resolution: Done
Merged.
> CLI shutting down a slave disconnects from the master
> -----------------------------------------------------
>
> Key: WFCORE-67
> URL: https://issues.jboss.org/browse/WFCORE-67
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 1.0.0.Alpha4
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> If I issue a shutdown command for a slave HC, the CLI gets disconnected:
> [domain@localhost:9999 /] shutdown --host=slave-a
> [disconnected /] shutdown --host=slave-b
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [disconnected /] cd /
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [disconnected /] connect
> [domain@localhost:9999 /] shutdown --host=slave-b
> [disconnected /]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
Frank Langelage updated WFLY-3778:
----------------------------------
Summary: Tests in Manualmode test suite fail occasionally (was: Test in Manualmode test suite fail occasionally)
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3778) Test in Manualmode test suite fail occasionally
by Frank Langelage (JIRA)
Frank Langelage created WFLY-3778:
-------------------------------------
Summary: Test in Manualmode test suite fail occasionally
Key: WFLY-3778
URL: https://issues.jboss.org/browse/WFLY-3778
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Remoting, Test Suite
Affects Versions: 9.0.0.Beta1
Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
Reporter: Frank Langelage
Assignee: David Lloyd
I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
But I saw a very similar failure today on Linux first time for PR 6638.
See https://github.com/wildfly/wildfly/pull/6638.
Last failure on my machine:
Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
java.lang.AssertionError: Password should be right and authentication successful
Expected: a string containing "\"outcome\" => \"success\""
but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
INFO [org.xnio] XNIO version 3.3.0.Beta1
INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:865)
at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Sean Flanigan (JIRA)
[ 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)
11 years, 2 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Sean Flanigan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Sean Flanigan commented on WFLY-3529:
-------------------------------------
Here's a little more information from the console log, including the thread names:
12:12:53,064 INFO [stdout] (default task-4) Thread name (SlowHttpSessionListener): default task-4
12:12:53,580 INFO [stdout] (default task-4) Thread name (LogoutServlet): default task-4
12:12:53,586 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /HelloWorld: java.lang.IllegalStateException: UT000010: Session not found 5t2J_pKU1WqHqYl6qXm13UMy
at io.undertow.server.session.InMemorySessionManager$SessionImpl.getMaxInactiveInterval(InMemorySessionManager.java:326) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout(InMemorySessionManager.java:253) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:337) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:33) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:14) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at org.jboss.weld.context.AbstractConversationContext.associate(AbstractConversationContext.java:139) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at org.jboss.weld.servlet.ConversationContextActivator.associateConversationContext(ConversationContextActivator.java:118) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:217) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:156) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
12:12:53,597 WARN [org.jboss.weld.Servlet] (default task-5) WELD-000712: Unable to dissociate context org.jboss.weld.context.http.LazyHttpConversationContextImpl@5c96cbb3 when destroying request io.undertow.servlet.spec.HttpServletRequestImpl@30178442
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Sean Flanigan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Sean Flanigan reopened WFLY-3529:
---------------------------------
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Sean Flanigan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Sean Flanigan updated WFLY-3529:
--------------------------------
Attachment: WFLY-3529.tar.gz
WFLY-3529.war
The attached war file (with source tar.gz) consistently reproduces the problem when the logout link is pressed, both on WildFly 8.1.0.Final and WildFly-latest-master #1354 (git commit 1b48a35be74721ebb812d9c5cfb4b34c31bf78e1). This is the exception on the master version:
java.lang.IllegalStateException: UT000010: Session not found 5t2J_pKU1WqHqYl6qXm13UMy
io.undertow.server.session.InMemorySessionManager$SessionImpl.getMaxInactiveInterval(InMemorySessionManager.java:326)
io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout(InMemorySessionManager.java:253)
io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:337)
io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121)
org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:33)
org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:14)
org.jboss.weld.context.AbstractConversationContext.associate(AbstractConversationContext.java:139)
org.jboss.weld.servlet.ConversationContextActivator.associateConversationContext(ConversationContextActivator.java:118)
org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:217)
org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:156)
io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:744)
> 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)
11 years, 2 months
[JBoss JIRA] (WFCORE-72) deploy --force fails in CLI GUI
by Stan Silvert (JIRA)
Stan Silvert created WFCORE-72:
----------------------------------
Summary: deploy --force fails in CLI GUI
Key: WFCORE-72
URL: https://issues.jboss.org/browse/WFCORE-72
Project: WildFly Core
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 1.0.0.Alpha5
Reporter: Stan Silvert
Assignee: Stan Silvert
Fix For: 1.0.0.Alpha6
The --force flag is not working with the deploy command in CLI GUI. The CLI CommandContextImpl is generating the wrong DMR request.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3754) EJB StatefulSessionComponentInstance methodMap includes final Object methods
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3754?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3754:
------------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
> EJB StatefulSessionComponentInstance methodMap includes final Object methods
> ----------------------------------------------------------------------------
>
> Key: WFLY-3754
> URL: https://issues.jboss.org/browse/WFLY-3754
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> StatefulSessionComponentInstance has a methodMap which maintains the ChainedInterceptors for each method. That currently includes final Object methods which are not Business Methods for EJBs (EJB 3.1 4.9.5 "The method must not be declared as final or static"), which results in extra memory overhead for what I believe is the useless interceptors.
> The amount of memory a ChainedInterceptor consumes varies between JVMs, but it is between 280 and 400 bytes in some heap dumps I looked at. With 6 final methods (wait, notify*, getClass) on java.lang.Object that adds approximately 2kb of memory use to each instance of each SFSB.
> This can affect all BasicComponentInstance subclasses, but it is most noticeable for SFSBs due to the larger number of instances.
> The list of methods comes from ComponentConfiguration.getDefinedComponentMethods(), but I'm not sure if filtering the final methods out should be done there or an EJB-specific class since the rule about final methods is from the EJB spec. I'm also not sure if toString, equals and hashCode() should be treated as EJB business methods either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months