[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11489:
--------------------------------------------
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out.
The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetNode, NONE) which works.
2. Generally, the only time the server should adjust affinity on onvocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a s SLSB is send to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ELYWEB-36) ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELYWEB-36?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELYWEB-36:
----------------------------------------
[~fjuma] I didn't think about the versioning, correct this should be for 1.4.x - although we are spacing the versioning to allow each WildFly release to have it's own maintenance stream I am thinking if we should in future stop pro-actively creating the branches.
In the future if one is needed we can always create from the last tag that went into that WildFly release and merge from the next branch down to seed it on demand.
> ElytronHttpExchange.getRequestParameters() is prematurely readying the request.
> -------------------------------------------------------------------------------
>
> Key: ELYWEB-36
> URL: https://issues.jboss.org/browse/ELYWEB-36
> Project: Elytron Web
> Issue Type: Bug
> Components: Undertow Servlet
> Affects Versions: 1.2.3.Final, 1.3.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.2.4.CR1, 1.3.1.CR1, 1.4.0.CR1
>
>
> When running within Undertow as a Servlet container the method ElytronHttpExchange.getRequestParameters() is prematurely reading the FormData making it unavailable to the HttpServletRequest.
> If instead of handling them manually the request parameters were read from the HttpServletRequest this would not be an issue as the request can re-use it's own prior FormData parsing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2327:
---------------------------
Description:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
h4. Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. Workaround
* Set GMS.leave_timeout to a higher value (say 8000ms)
h4. Solution
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
was:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. Workaround
* Set GMS.leave_timeout to a higher value (say 8000ms)
h4. Solution
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.17
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> h4. Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2327:
---------------------------
Description:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. Workaround
* Set GMS.leave_timeout to a higher value (say 8000ms)
h4. Solution
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
was:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. WORKAROUND
*Set GMS.leave_timeout to a higher value (say 8000ms)
h4. SOLUTION
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.17
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
Bela Ban created JGRP-2327:
------------------------------
Summary: UNICAST3: create receiver table when non-first message is received first
Key: JGRP-2327
URL: https://issues.jboss.org/browse/JGRP-2327
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.17
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. WORKAROUND
*Set GMS.leave_timeout to a higher value (say 8000ms)
h4. SOLUTION
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously
by Ian Rodgers (Jira)
[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ]
Ian Rodgers commented on WFLY-11535:
------------------------------------
[~pferraro] - Yes, we're using Keycloak 4.6.0 which uses Wildfly 14 under the covers - https://www.keycloak.org/docs/latest/release_notes/index.html#keycloak-4-...
According to the logs it includes JGroups 4.0.13 which supposedly fixes JGRP-2281.
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/keycloak
JAVA: /usr/lib/jvm/java/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
INFO [org.jboss.modules] (main) JBoss Modules version 1.8.6.Final
INFO [org.jboss.msc] (main) JBoss MSC version 1.4.3.Final
INFO [org.jboss.threads] (main) JBoss Threads version 2.3.2.Final
INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: Keycloak 4.6.0.Final (WildFly Core 6.0.2.Final) starting
INFO [org.wildfly.security] (ServerService Thread Pool -- 20) ELY00001: WildFly Elytron version 1.6.0.Final
INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the depr
INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 4) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 9) WFLYCTL0028: Attribute 'permissions' in the resource at address '/subsystem=elytron/constant-permission-mapper=constant-permission-mapper' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn mo
INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more abo
INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.6.5.Final
INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.6.5.Final
INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) WFLYCLINF0001: Activating Infinispan subsystem.
INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 4.0.13
INFO [org.jboss.as.naming] (ServerService Thread Pool -- 43) WFLYNAM0001: Activating Naming Subsystem
INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 35) WFLYIO001: Worker 'default' has auto-configured to 2 core threads with 16 task threads based on your 1 available processors
WARN [org.jboss.as.txn] (ServerService Thread Pool -- 48) WFLYTX0013: The node-identifier attribute on the /subsystem=transactions is set to the default value. This is a danger for environments running multiple servers. Please make sure the attribute value is unique.
INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 36) WFLYRS0016: RESTEasy version 3.6.1.Final
INFO [org.jboss.as.security] (ServerService Thread Pool -- 46) WFLYSEC0002: Activating Security Subsystem
INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.11.Final)
INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 29) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.4)
INFO [org.jboss.as.security] (MSC service thread 1-2) WFLYSEC0001: Current PicketBox version=5.0.3.Final
INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 29) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 42.2)
INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 2.0.13.Final starting
> Cluster fails to merge if instances started simultaneously
> ----------------------------------------------------------
>
> Key: WFLY-11535
> URL: https://issues.jboss.org/browse/WFLY-11535
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster
> Reporter: Ian Rodgers
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: standalone-ha.xml
>
>
> Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).
> We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join.
> This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix.
> On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3492) Create UX proposal to show/edit Test Scenario (Preview) global setting
by tao zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3492?page=com.atlassian.jira.plugi... ]
tao zhu commented on DROOLS-3492:
---------------------------------
Hi [~kkufova] The last icon may be updated to "coverage report"
!屏幕快照 2019-01-22 下午4.44.04.png|thumbnail!
> Create UX proposal to show/edit Test Scenario (Preview) global setting
> ----------------------------------------------------------------------
>
> Key: DROOLS-3492
> URL: https://issues.jboss.org/browse/DROOLS-3492
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: tao zhu
> Priority: Major
> Labels: ScenarioSimulation, UXD, UXTeam
> Attachments: 11unnamed.png, TestScenario_Cheatsheet.png, TestScenario_TestEditor.png, TestScenario_TestReport.png, TestScenario_whole.png, test-report-icon.png, 屏幕快照 2019-01-22 下午4.44.04.png
>
>
> As user I want to be able to see/edit editor global settings.
> For instance DMN file linked to the scenario or the Session name of a Rule scenario
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3492) Create UX proposal to show/edit Test Scenario (Preview) global setting
by tao zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3492?page=com.atlassian.jira.plugi... ]
tao zhu updated DROOLS-3492:
----------------------------
Attachment: 屏幕快照 2019-01-22 下午4.44.04.png
> Create UX proposal to show/edit Test Scenario (Preview) global setting
> ----------------------------------------------------------------------
>
> Key: DROOLS-3492
> URL: https://issues.jboss.org/browse/DROOLS-3492
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: tao zhu
> Priority: Major
> Labels: ScenarioSimulation, UXD, UXTeam
> Attachments: 11unnamed.png, TestScenario_Cheatsheet.png, TestScenario_TestEditor.png, TestScenario_TestReport.png, TestScenario_whole.png, test-report-icon.png, 屏幕快照 2019-01-22 下午4.44.04.png
>
>
> As user I want to be able to see/edit editor global settings.
> For instance DMN file linked to the scenario or the Session name of a Rule scenario
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months