[JBoss JIRA] (WFLY-10024) Stale session data on failover
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10024?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10024:
-----------------------------------
Description:
The version used is the latest at the time of execution i.e. WildFly Full 13.0.0.Alpha1-SNAPSHOT
Scenario: failover-http-session-jvmkill-repl-sync (i.e. with REPL cache and SYNC replication)
When the node failover starts (node JVMs start getting killed) we see the following exception on the client side:
{code:java}
2018/03/09 12:13:03:209 EST [WARN ][Runner - 1597] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
{code}
Looks like this bug is related to a previous one marked as verified : https://issues.jboss.org/browse/WFLY-6225
was:
WildFly Full 13.0.0.Alpha1-SNAPSHOT
Scenario: failover-http-session-jvmkill-repl-sync (i.e. with REPL cache and SYNC replication)
When the node failover starts (node JVMs start getting killed) we see the following exception on the client side:
{code:java}
2018/03/09 12:13:03:209 EST [WARN ][Runner - 1597] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
{code}
Looks like this bug is related to a previous one marked as verified : https://issues.jboss.org/browse/WFLY-6225
> Stale session data on failover
> ------------------------------
>
> Key: WFLY-10024
> URL: https://issues.jboss.org/browse/WFLY-10024
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
> Labels: clustering, wildfly
>
> The version used is the latest at the time of execution i.e. WildFly Full 13.0.0.Alpha1-SNAPSHOT
> Scenario: failover-http-session-jvmkill-repl-sync (i.e. with REPL cache and SYNC replication)
> When the node failover starts (node JVMs start getting killed) we see the following exception on the client side:
> {code:java}
> 2018/03/09 12:13:03:209 EST [WARN ][Runner - 1597] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Looks like this bug is related to a previous one marked as verified : https://issues.jboss.org/browse/WFLY-6225
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-10024) Stale session data on failover
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10024?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10024:
-----------------------------------
Summary: Stale session data on failover (was: Stale data)
> Stale session data on failover
> ------------------------------
>
> Key: WFLY-10024
> URL: https://issues.jboss.org/browse/WFLY-10024
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
> Labels: clustering, wildfly
>
> WildFly Full 13.0.0.Alpha1-SNAPSHOT
> Scenario: failover-http-session-jvmkill-repl-sync (i.e. with REPL cache and SYNC replication)
> When the node failover starts (node JVMs start getting killed) we see the following exception on the client side:
> {code:java}
> 2018/03/09 12:13:03:209 EST [WARN ][Runner - 1597] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Looks like this bug is related to a previous one marked as verified : https://issues.jboss.org/browse/WFLY-6225
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-10024) Stale data
by tommaso borgato (JIRA)
tommaso borgato created WFLY-10024:
--------------------------------------
Summary: Stale data
Key: WFLY-10024
URL: https://issues.jboss.org/browse/WFLY-10024
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 13.0.0.Beta1
Reporter: tommaso borgato
Assignee: Paul Ferraro
WildFly Full 13.0.0.Alpha1-SNAPSHOT
Scenario: failover-http-session-jvmkill-repl-sync (i.e. with REPL cache and SYNC replication)
When the node failover starts (node JVMs start getting killed) we see the following exception on the client side:
{code:java}
2018/03/09 12:13:03:209 EST [WARN ][Runner - 1597] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 64, received 63, Runner: 1597
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
{code}
Looks like this bug is related to a previous one marked as verified : https://issues.jboss.org/browse/WFLY-6225
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1503) SPNEGO fails on <distributable/> deployment
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1503?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1503:
----------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1097
> SPNEGO fails on <distributable/> deployment
> -------------------------------------------
>
> Key: ELY-1503
> URL: https://issues.jboss.org/browse/ELY-1503
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 1.2.1.Final, 1.3.0.CR1
>
>
> Session-scoped (default) SPNEGO authentication does not work on </distributable> deployments.
> Works on CONNECTION and NONE scoped.
> {code}
> 07:09:42,554 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /3246302d-d806-4441-ab87-1cf291a618d5/protected/SimpleSecuredServlet: java.lang.IllegalArgumentException: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributes.setAttribute(CoarseSessionAttributes.java:71)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.setAttribute(DistributableSession.java:176)
> at io.undertow.servlet.spec.HttpSessionImpl.setAttribute(HttpSessionImpl.java:169)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService$4.setAttachment(ApplicationSecurityDomainDefinition.java:676)
> at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:199)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (SWSQE-68) [QE] SWS-159
by Matt Mahoney (JIRA)
Matt Mahoney created SWSQE-68:
---------------------------------
Summary: [QE] SWS-159
Key: SWSQE-68
URL: https://issues.jboss.org/browse/SWSQE-68
Project: Swift Sunshine QE
Issue Type: Task
Reporter: Matt Mahoney
Assignee: Michael Foley
"As a SWS user I would like to be able to selectively view metrics about a connection between services on the service graph to get more information about the health and state of the connection"
For example, if I click on a connection, a side pane could open up that contains metric graphs
[link title|https://issues.jboss.org/browse/SWS-159]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months