[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
[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
[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
[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
[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
[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
[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml
by Michael Biarnes Kiefer (Jira)
[ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-2254:
-------------------------------------------
Fix Version/s: 7.30.0.Final
(was: 7.29.0.Final)
> Automate .proto files rebuild in pom.xml
> ----------------------------------------
>
> Key: DROOLS-2254
> URL: https://issues.jboss.org/browse/DROOLS-2254
> Project: Drools
> Issue Type: Task
> Components: tools
> Affects Versions: 7.5.0.Final
> Reporter: Dmitry Volodin
> Assignee: Dmitry Volodin
> Priority: Minor
> Fix For: 7.30.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
