[JBoss JIRA] (WFLY-12727) Upgrade Netty to 4.1.42
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-12727:
----------------------------------------
Summary: Upgrade Netty to 4.1.42
Key: WFLY-12727
URL: https://issues.jboss.org/browse/WFLY-12727
Project: WildFly
Issue Type: Component Upgrade
Components: JMS
Affects Versions: 18.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
Upgrade Netty to 4.1.42
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12718:
------------------------------------
Description:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
We also repeated the tests to make sure it can be reproduced:
- **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
was:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
We also repeated the tests to make sure it can be reproduced:
- **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-12718:
---------------------------------------
Which are caused by servers running out of heap space.
{noformat}
2019-10-28 18:48:14,097 ERROR [org.jgroups.blocks.RequestCorrelator] (ChannelCommandDispatcherFactory - 23) JGRP000178: failed marshalling rsp (null): java.lang.OutOfMemoryError: Java heap space
{noformat}
Can you check the test runs had correct values of java heap space available?
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4734) Upgrade jackson-databind test dependency to 2.9.10.1
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4734:
----------------------------------------
Summary: Upgrade jackson-databind test dependency to 2.9.10.1
Key: WFCORE-4734
URL: https://issues.jboss.org/browse/WFCORE-4734
Project: WildFly Core
Issue Type: Component Upgrade
Components: Security
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The elytron subsystem maven module uses jackson-databind as a test dep. The version used has CVEs and the 2.9.10.1 version used in production in full works, so even though this is just a test dep lets upgrade it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-12718:
---------------------------------------
The exceptions in the test log are timeouts.
{noformat}
2019-10-28 18:48:01,307 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand on Cache 'clusterbench-ee8.ear.clusterbench-ee8-web.war', writing keys [SessionAccessMetaDataKey(SSpenckNGHL1Y20-8vGPxHRvN-ASy2Xo19q09mJi), SessionCreationMetaDataKey(SSpenckNGHL1Y20-8vGPxHRvN-ASy2Xo19q09mJi)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 228131 from wildfly2
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
2019-10-28 18:48:01,305 ERROR [org.infinispan.transaction.impl.TransactionCoordinator] (default task-155) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 228130 from wildfly2
at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:156)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
at org.wildfly.clustering.ee.cache@18.0.0.Final//org.wildfly.clustering.ee.cache.tx.TransactionalBatch.close(TransactionalBatch.java:98)
at org.wildfly.clustering.web.undertow@18.0.0.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:950)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:621)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core@2.0.26.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.core@2.0.26.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 228130 from wildfly2
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
at org.infinispan@9.4.16.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
... 1 more
Suppressed: org.infinispan.util.logging.TraceException
at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:41)
at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:250)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:156)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
at org.infinispan@9.4.16.Final//org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
at org.wildfly.clustering.ee.cache@18.0.0.Final//org.wildfly.clustering.ee.cache.tx.TransactionalBatch.close(TransactionalBatch.java:98)
at org.wildfly.clustering.web.undertow@18.0.0.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:950)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:621)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.26.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core@2.0.26.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.core@2.0.26.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
... 1 more
{noformat}
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4705) Drools/Kie-Server/Busines-Central 7.28.0 Is getting a 403 when kie-server accesses the websocket controller on business-central
by Maciej Swiderski (Jira)
[ https://issues.jboss.org/browse/DROOLS-4705?page=com.atlassian.jira.plugi... ]
Maciej Swiderski commented on DROOLS-4705:
------------------------------------------
There is a need for new role to be added to user in used to connect to Business Central - that role is "rest-all" once that is assigned to the user it should allow to access the controller endpoint.
> Drools/Kie-Server/Busines-Central 7.28.0 Is getting a 403 when kie-server accesses the websocket controller on business-central
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4705
> URL: https://issues.jboss.org/browse/DROOLS-4705
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.24.0.Final, 7.25.0.Final, 7.28.0.Final
> Environment: Linux, JDK8, and Wildfly 14.0.1
> Reporter: Danny Rucker
> Assignee: Maciej Swiderski
> Priority: Major
> Fix For: 7.23.0.Final
>
>
> We're upgrading our business-central server from 7.23.0 to 7.28.0. We're noticing that our kie-servers can no longer connect via websocket to business-central:
> Server logs:
> {quote}
> Oct 28 12:56:43 business-central-1 business-central[18870]: #033[0m#033[0m12:56:43,962 INFO [org.kie.server.controller.websocket.notification.WebSocketNotificationService] (Thread-123) WebSocket notify on updated :: Updated server template{serverTemplate=ServerTemplateKey{id='host.subdomain.x.com', name='host.subdomain.x.com'}, resetBeforeUpdate=false}
> Oct 28 12:56:43 business-central-1 business-central[18870]: #033[0m#033[0m12:56:43,963 INFO [org.kie.server.controller.websocket.notification.WebSocketNotificationService] (Thread-123) WebSocket notify on instance disconnected :: ServerInstanceDisconnected{serverInstanceId='host.subdomain.x.com@host.subdomain.x.com:36204'}
> {quote}
> Client logs:
> {quote}
> Oct 28 20:21:53 host kie-server[1375]: #033[0m#033[33m20:21:53,090 WARN [org.kie.server.common.KeyStoreHelperUtil] (KieServer-ControllerConnect) Unable to load key store. Using password from configuration
> Oct 28 20:21:53 host kie-server[1375]: #033[0m#033[33m20:21:53,146 WARN [org.kie.server.controller.websocket.client.WebSocketKieServerControllerImpl] (KieServer-ControllerConnect) Exception encountered while syncing with controller at wss://business-central-1.x.com/business-central/websocket/controller/host... error Invalid response code 403
> {quote}
> The actual break occurred between 7.23.0 and 7.24.0, as 7.24.0 produces the same error message: Invalid response code 403.
> The user that kie-server is connecting to business-central with has kie-server as a group, but that doesn't seem to help. We're running business-central on Wildfly 14.0.1.
> I'm looking through the commits for a web.xml change for filtering web reources but can't seem to find anything. Actually, I'm not even sure which github project I should be looking in: https://github.com/kiegroup
> tcpdump from 7.24.0+ versions(none worked):
> {quote}
> GET /business-central/websocket/controller/apps-3-staging HTTP/1.1
> Authorization: Basic <base64-stuff-here>
> Sec-WebSocket-Key: YZ5r8liCJKut6VJ2YG7sPQ==
> Connection: upgrade
> Sec-WebSocket-Version: 13
> Upgrade: websocket
> Host: localhost:8080
> HTTP/1.1 403 Forbidden
> Expires: 0
> Cache-Control: no-cache, no-store, must-revalidate
> X-Powered-By: JSP/2.3
> Set-Cookie: JSESSIONID=cBz0q1sK09Fq2jtXA8Mad1FHPKxvQ38akKGNMP9R.business-central-1; path=/business-central; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
> Pragma: no-cache
> Date: Mon, 28 Oct 2019 18:23:21 GMT
> Connection: keep-alive
> Content-Type: text/html;charset=UTF-8
> Content-Length: 1102
> Content-Language: en-
> {quote}
> tcpdump from 7.23.0 version(which works):
> {quote}
> GET /business-central/websocket/controller/apps-3-staging HTTP/1.1
> Authorization: Basic <base64-stuff-here>
> Sec-WebSocket-Key: yhykxYXh0z+KF0Zv/8P76g==
> Connection: upgrade
> Sec-WebSocket-Version: 13
> Host: localhost:8080
> Upgrade: websocket
> HTTP/1.1 101 Switching Protocols
> Connection: Upgrade
> Set-Cookie: JSESSIONID=UCZsXbdV1ZUjTBTOcbP9j-ppd3y2NH0mzOqPQcjP.business-central; path=/business-central; HttpOnly
> Sec-WebSocket-Location: wss://business-central-1/business-central/websocket/controller/apps-3-staging
> X-XSS-Protection: 1; mode=block
> Upgrade: WebSocket
> X-FRAME-OPTIONS: SAMEORIGIN
> Sec-WebSocket-Accept: 6qSH/TZNvoukpIE+ZJYulWzGge0=
> Date: Mon, 28 Oct 2019 17:21:57 GMT
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4705) Drools/Kie-Server/Busines-Central 7.28.0 Is getting a 403 when kie-server accesses the websocket controller on business-central
by Danny Rucker (Jira)
Danny Rucker created DROOLS-4705:
------------------------------------
Summary: Drools/Kie-Server/Busines-Central 7.28.0 Is getting a 403 when kie-server accesses the websocket controller on business-central
Key: DROOLS-4705
URL: https://issues.jboss.org/browse/DROOLS-4705
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.28.0.Final, 7.25.0.Final, 7.24.0.Final
Environment: Linux, JDK8, and Wildfly 14.0.1
Reporter: Danny Rucker
Assignee: Maciej Swiderski
Fix For: 7.23.0.Final
We're upgrading our business-central server from 7.23.0 to 7.28.0. We're noticing that our kie-servers can no longer connect via websocket to business-central:
Server logs:
{quote}
Oct 28 12:56:43 business-central-1 business-central[18870]: #033[0m#033[0m12:56:43,962 INFO [org.kie.server.controller.websocket.notification.WebSocketNotificationService] (Thread-123) WebSocket notify on updated :: Updated server template{serverTemplate=ServerTemplateKey{id='host.subdomain.x.com', name='host.subdomain.x.com'}, resetBeforeUpdate=false}
Oct 28 12:56:43 business-central-1 business-central[18870]: #033[0m#033[0m12:56:43,963 INFO [org.kie.server.controller.websocket.notification.WebSocketNotificationService] (Thread-123) WebSocket notify on instance disconnected :: ServerInstanceDisconnected{serverInstanceId='host.subdomain.x.com@host.subdomain.x.com:36204'}
{quote}
Client logs:
{quote}
Oct 28 20:21:53 host kie-server[1375]: #033[0m#033[33m20:21:53,090 WARN [org.kie.server.common.KeyStoreHelperUtil] (KieServer-ControllerConnect) Unable to load key store. Using password from configuration
Oct 28 20:21:53 host kie-server[1375]: #033[0m#033[33m20:21:53,146 WARN [org.kie.server.controller.websocket.client.WebSocketKieServerControllerImpl] (KieServer-ControllerConnect) Exception encountered while syncing with controller at wss://business-central-1.x.com/business-central/websocket/controller/host... error Invalid response code 403
{quote}
The actual break occurred between 7.23.0 and 7.24.0, as 7.24.0 produces the same error message: Invalid response code 403.
The user that kie-server is connecting to business-central with has kie-server as a group, but that doesn't seem to help. We're running business-central on Wildfly 14.0.1.
I'm looking through the commits for a web.xml change for filtering web reources but can't seem to find anything. Actually, I'm not even sure which github project I should be looking in: https://github.com/kiegroup
tcpdump from 7.24.0+ versions(none worked):
{quote}
GET /business-central/websocket/controller/apps-3-staging HTTP/1.1
Authorization: Basic <base64-stuff-here>
Sec-WebSocket-Key: YZ5r8liCJKut6VJ2YG7sPQ==
Connection: upgrade
Sec-WebSocket-Version: 13
Upgrade: websocket
Host: localhost:8080
HTTP/1.1 403 Forbidden
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate
X-Powered-By: JSP/2.3
Set-Cookie: JSESSIONID=cBz0q1sK09Fq2jtXA8Mad1FHPKxvQ38akKGNMP9R.business-central-1; path=/business-central; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
Pragma: no-cache
Date: Mon, 28 Oct 2019 18:23:21 GMT
Connection: keep-alive
Content-Type: text/html;charset=UTF-8
Content-Length: 1102
Content-Language: en-
{quote}
tcpdump from 7.23.0 version(which works):
{quote}
GET /business-central/websocket/controller/apps-3-staging HTTP/1.1
Authorization: Basic <base64-stuff-here>
Sec-WebSocket-Key: yhykxYXh0z+KF0Zv/8P76g==
Connection: upgrade
Sec-WebSocket-Version: 13
Host: localhost:8080
Upgrade: websocket
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Set-Cookie: JSESSIONID=UCZsXbdV1ZUjTBTOcbP9j-ppd3y2NH0mzOqPQcjP.business-central; path=/business-central; HttpOnly
Sec-WebSocket-Location: wss://business-central-1/business-central/websocket/controller/apps-3-staging
X-XSS-Protection: 1; mode=block
Upgrade: WebSocket
X-FRAME-OPTIONS: SAMEORIGIN
Sec-WebSocket-Accept: 6qSH/TZNvoukpIE+ZJYulWzGge0=
Date: Mon, 28 Oct 2019 17:21:57 GMT
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
