[JBoss JIRA] (WFWIP-36) [pretesting] IllegalStateException: WFLYCLWEBUT0002: Session X already exists in session offloading scenario with hotrod store configured
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFWIP-36?page=com.atlassian.jira.plugin.s... ]
Michal Vinkler commented on WFWIP-36:
-------------------------------------
The scenario now runs successfully with the transactions+pessimistic locking enabled on the JDG cache (i.e. WFWIP-37 is fixed). However, this issue is still occuring and number of sampling errors is still the same - ~1700 ([link to run|http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failov...]) compared to ~70 in the scenario with remote store configured ([link to run|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-...]).
> [pretesting] IllegalStateException: WFLYCLWEBUT0002: Session X already exists in session offloading scenario with hotrod store configured
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-36
> URL: https://issues.jboss.org/browse/WFWIP-36
> Project: WildFly WIP
> Issue Type: Bug
> Components: Clustering
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
> Priority: Critical
>
> We hit an issue when running tests for RFE EAP7-942.
> Wildfly was built from https://github.com/rhusar/wildfly/tree/WFLY-9294
> Scenario:
> 2-node Wildfly cluster + 2-node JDG 7.2.0.CR1 cluster.
> Wildfly servers are configured to use hotrod store which is backed up by JDG cluster.
> Each Wildfly node is gracefully shut down and then started up again.
> Wildfly configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-r...
> JDG configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-r...
> When perf18 shut down, perf19 logged one time:
> {code}
> ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /clusterbench-offload/session: java.lang.IllegalStateException: WFLYCLWEBUT0002: Session M4qPQhyKwIG6vYTdLTxuyO_wqcKUABbRVtLtkEy_ already exists
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:124)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:918)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:412)
> [JBossINF] at org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet.doGet(CommonHttpSessionServlet.java:38)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {code}
> Server log:
> https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-...
> Please note, that in this test run, number of clients was lowered to 10 (!). With the standard number of clients (2000), the exception occurs around 100 times, as can be seen in this run:
> https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-...
> On the client, this issue (and maybe others as well) manifests as *very stale data* received:
> {code}
> 2018/05/11 02:35:17:934 EDT [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:test - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 30, received 1, Runner: 16>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 30, received 1, Runner: 16
> 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}
> Client log:
> https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-...
> There were only 14 sampling errors in the run with 10 clients. However, with 2000 clients, there are around 1700 sampling errors (just for 2 failovers happening in the test):
> https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-...
> The JDG uses default cache. When trying to add transactions for the cache, I hit another issue: WFWIP-37.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10369) Wildfly jms client bom nightly releases
by Martin Styk (JIRA)
Martin Styk created WFLY-10369:
----------------------------------
Summary: Wildfly jms client bom nightly releases
Key: WFLY-10369
URL: https://issues.jboss.org/browse/WFLY-10369
Project: WildFly
Issue Type: Feature Request
Components: JMS
Reporter: Martin Styk
Assignee: Jeff Mesnil
Currently {{widlfly-jms-client-bom}} is released only with WildFly releases.
Early testing of jms client bom dependency is not possible. Periodic nightly/weekly releases of bom (possibly SNAPSHOT) would encourage agile workflow and help us to test it and find issues in advance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-200) B12 OpenShift Cluster is flaky
by Kevin Earls (JIRA)
[ https://issues.jboss.org/browse/SWSQE-200?page=com.atlassian.jira.plugin.... ]
Kevin Earls reopened SWSQE-200:
-------------------------------
Sorry [~gbaufake] but I don't think we can say this is done yet. When I came in this morning the elasticsearch cluster that I had left running yesterday was in a failed state even though nothing had been using it. I shut it down and tried to redeploy, but so far that's not working. I get the following message in the monitoring/events page:
Failed Create Pod Sand Box Failed create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "elasticsearch-0": Error response from daemon: grpc: the connection is unavailable
174 times in the last
Can you at least restart the cluster so I can try to finish up a couple of things today?
Also we should probably leave this bug open (or replace it with more specific ones) until we're sure we have a healthy cluster. Thanks.
> B12 OpenShift Cluster is flaky
> ------------------------------
>
> Key: SWSQE-200
> URL: https://issues.jboss.org/browse/SWSQE-200
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
> Priority: Minor
>
> I'm opening this mostly as a placeholder, and will update it as I get more information on the problems I've been experiencing. Since I've been using B12 I've been experiencing more frequent failures than on other clusters, including minishift on my laptop and the CNCF CI Jenkins. Here are a couple of instances:
> 1. Deploying ElasticSearch along with the Jaeger Production templates requires allocating 2G or memory, even though the default 512M works fine elsewhere. This can be seen in the Jaeger Standalone Performance tests job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/J... . If you run the job without changing the ES_MEMORY parameter to 2Gi it will fail.
> 2. I have a set of smoke tests for Red Hat productized artifacts for the Jaeger Java client which are run using the Jaeger all-in-one template. It's fairly simple, but on B12 deployment of the Jaeger all-in-one images fails on every other build. I've made a copy of the job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/F... and its history should be clear.
> So far I have not been able to get any useful information about why this is failing. In the OpenShift console it looks like Jaeger has started correctly. There are no errors in the logs, nor any to be found under monitoring. But if you click on the Jaeger link, you get the message "Application is not available . The application is currently not serving requests at this endpoint. It may not have been started or is still starting."
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10339:
------------------------------------
Just a note that I reverted WFLY-9989 as this issue should not block the release of WildFly 13.
Once WildFly 13 is released, we will be able to cherry-pick the version bump again without any issue.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3849) CLI curosr disorder for Up and Down Arrow
by Chao Wang (JIRA)
Chao Wang created WFCORE-3849:
---------------------------------
Summary: CLI curosr disorder for Up and Down Arrow
Key: WFCORE-3849
URL: https://issues.jboss.org/browse/WFCORE-3849
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 5.0.0.Beta2
Reporter: Chao Wang
Assignee: Jean-Francois Denise
Priority: Critical
Connect to CLI and click keyboard up and down arrows (assuming there is history commands there). Terminal cursor moves up in a confused manner. This happens since WFCORE Beta 1 version.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10349) WeldBundledLibraryDeployment Test cases fail on IBM jdk
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-10349?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFLY-10349:
---------------------------------------
This was fixed by wildfly-core update to 5.0.0.Beta2 (dbd43ade41).
> WeldBundledLibraryDeployment Test cases fail on IBM jdk
> -------------------------------------------------------
>
> Key: WFLY-10349
> URL: https://issues.jboss.org/browse/WFLY-10349
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Environment: {noformat}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 1.8.0_161, vendor: IBM Corporation
> Java home: /usr/lib/java/ibm-java-8.0-5.11/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.17-300.fc27.x86_64", arch: "amd64", family: "unix"
> $ git rev-parse --short HEAD
> 11e21f08d3
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> WeldBundledLibraryDeploymentEarTestCase and WeldBundledLibraryDeploymentTestCase fails on IBM jdk.
> *reproduce*
> {noformat}
> git clone https://github.com/wildfly/wildfly.git ; cd wildfly
> mvn clean install -B -DskipTests
> cd testsuite/integration/basic
> mvn test -Dtest=WeldBundledLibraryDeploymentEarTestCase,WeldBundledLibraryDeploymentTestCase -DtestLogToFile=false
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR] WeldBundledLibraryDeploymentEarTestCase.org.jboss.as.test.integration.weld.multideployment.WeldBundledLibraryDeploymentEarTestCase » Deployment
> [ERROR] WeldBundledLibraryDeploymentTestCase.org.jboss.as.test.integration.weld.multideployment.WeldBundledLibraryDeploymentTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
> {noformat}
>
> *server log errors*
> {noformat}
> 11:56:22,104 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.extension-index: org.jboss.msc.service.StartException in service jboss.deployment.extension-index: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:811)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.server.moduleservice.ExtensionIndexService.start(ExtensionIndexService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
> 11:56:22,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "2b7495c2-60cb-4e65-8c99-4decc85ace30.ear")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"],
> "Services that may be the cause:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"]
> }}
> 11:56:22,261 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "2b7495c2-60cb-4e65-8c99-4decc85ace30.ear" was rolled back with the following failure message:
> {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"],
> "Services that may be the cause:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"]
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months