[JBoss JIRA] (JBJCA-1211) Support JDK 8
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1211:
--------------------------------------
Summary: Support JDK 8
Key: JBJCA-1211
URL: https://issues.jboss.org/browse/JBJCA-1211
Project: IronJacamar
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build, JDBC
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.0.CR1
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 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:
----------------------------------
Attachment: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt
org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt
TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
> 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
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> 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, 10 months
[JBoss JIRA] (WFLY-3780) DS stats return wrong value types
by Heiko Braun (JIRA)
Heiko Braun created WFLY-3780:
---------------------------------
Summary: DS stats return wrong value types
Key: WFLY-3780
URL: https://issues.jboss.org/browse/WFLY-3780
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
the datasource stats declare model type INT, but return a String instead:
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" =>
{ "ActiveCount" => "1", "AvailableCount" => "20", "AverageBlockingTime" => "0", "AverageCreationTime" => "1", "CreatedCount" => "1", "DestroyedCount" => "0", "InUseCount" => "0", "MaxCreationTime" => "1", "MaxUsedCount" => "1", "MaxWaitCount" => "0", "MaxWaitTime" => "0", "TimedOut" => "0", "TotalBlockingTime" => "0", "TotalCreationTime" => "1", "statistics-enabled" => true }
}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 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 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months