February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3614?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-3614: ------------------------------------- I think the root cause is here https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-stunn... > [DMN Designer] Maximize Event brings palette to expression editor > ----------------------------------------------------------------- > > Key: DROOLS-3614 > URL: https://issues.jboss.org/browse/DROOLS-3614 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-02-07 14-25-52.png > > > If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Jozef Marko (Jira)

Jozef Marko created DROOLS-3614: ----------------------------------- Summary: [DMN Designer] Maximize Event brings palette to expression editor Key: DROOLS-3614 URL: https://issues.jboss.org/browse/DROOLS-3614 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Jozef Marko Assignee: Michael Anstis Attachments: Screenshot from 2019-02-07 14-25-52.png If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[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 updated WFLY-11489: --------------------------------------- Fix Version/s: 16.0.0.Beta1 > 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 > Fix For: 16.0.0.Beta1 > > 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)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Jörg Bäsner (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Jörg Bäsner updated WFLY-11682: ------------------------------- Steps to Reproduce: # Install a plain WildFly server # Build the {{playground.zip}} project attached to this Jira using Maven # Copy the build {{playground.jar}} to {{$JBOSS_HOME/standalone/deployments}} # Multiply the {{standalone}} folder into {{node1}}, {{node2}} and {{node3}} # Start the servers: {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.server.base.dir=$JBOSS_HOME/node1}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.server.base.dir=$JBOSS_HOME/node2 -Djboss.socket.binding.port-offset=300}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node3 -Djboss.server.base.dir=$JBOSS_HOME/node3 -Djboss.socket.binding.port-offset=600}} # start the client (300 = 5 minutes): {{mvn -f playground-jar/pom.xml exec:exec -Druntime=300}} # Stop {{node1}} # Stop {{node2}} # Stop {{node3}} # Start {{node1}} (see above) again # Observe {{node3}} in the list of available node, see: {{INFO (ThreadPoolTaskExecutor-5) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'}} was: # Install a plain WildFly server # Build the {{playground.zip}} project attached to this Jira using Maven # Copy the build 'playground.jar' to $JBOSS_HOME/standalone/deployments # Multiply the {{standalone}} folder into {{node1}}, {{node2}} and {{node3}} # Start the servers: {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.server.base.dir=$JBOSS_HOME/node1}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.server.base.dir=$JBOSS_HOME/node2 -Djboss.socket.binding.port-offset=300}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node3 -Djboss.server.base.dir=$JBOSS_HOME/node3 -Djboss.socket.binding.port-offset=600}} # start the client (300 = 5 minutes): {{mvn -f playground-jar/pom.xml exec:exec -Druntime=300}} # Stop {{node1}} # Stop {{node2}} # Stop {{node3}} # Start {{node1}} (see above) again # Observe {{node3}} in the list of available node, see: {{INFO (ThreadPoolTaskExecutor-5) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'}} > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Jörg Bäsner (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Jörg Bäsner updated WFLY-11682: ------------------------------- Steps to Reproduce: # Install a plain WildFly server # Build the {{playground.zip}} project attached to this Jira using Maven # Copy the build 'playground.jar' to $JBOSS_HOME/standalone/deployments # Multiply the {{standalone}} folder into {{node1}}, {{node2}} and {{node3}} # Start the servers: {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.server.base.dir=$JBOSS_HOME/node1}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.server.base.dir=$JBOSS_HOME/node2 -Djboss.socket.binding.port-offset=300}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node3 -Djboss.server.base.dir=$JBOSS_HOME/node3 -Djboss.socket.binding.port-offset=600}} # start the client (300 = 5 minutes): {{mvn -f playground-jar/pom.xml exec:exec -Druntime=300}} # Stop {{node1}} # Stop {{node2}} # Stop {{node3}} # Start {{node1}} (see above) again # Observe {{node3}} in the list of available node, see: {{INFO (ThreadPoolTaskExecutor-5) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'}} was: # Install a plain WildFly server # Build the {{playground.zip}} project attached to this Jira using Maven # Copy the build 'playground.jar' to $JBOSS_HOME/standalone/deployments # Multiply the {{standalone}} folder into {{node1}}, {{node2}} and {{node3}} # Start the servers: {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.server.base.dir=$JBOSS_HOME/node1}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.server.base.dir=$JBOSS_HOME/node2 -Djboss.socket.binding.port-offset=300}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node3 -Djboss.server.base.dir=$JBOSS_HOME/node3 -Djboss.socket.binding.port-offset=600}} # start the client (300 = 5 minutes): {{mvn -f playground-jar/pom.xml exec:exec -Druntime=300}} # Stop {{node1}} # Stop {{node2}} # Stop {{node3}} # Start {{node1}} (see above) again # observe {{node3}} in the list of available node, see: {{INFO (ThreadPoolTaskExecutor-5) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'}} > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Jörg Bäsner (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Jörg Bäsner updated WFLY-11682: ------------------------------- Steps to Reproduce: # Install a plain WildFly server # Build the {{playground.zip}} project attached to this Jira using Maven # Copy the build 'playground.jar' to $JBOSS_HOME/standalone/deployments # Multiply the {{standalone}} folder into {{node1}}, {{node2}} and {{node3}} # Start the servers: {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.server.base.dir=$JBOSS_HOME/node1}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.server.base.dir=$JBOSS_HOME/node2 -Djboss.socket.binding.port-offset=300}} {{$JBOSS_HOME/bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node3 -Djboss.server.base.dir=$JBOSS_HOME/node3 -Djboss.socket.binding.port-offset=600}} # start the client (300 = 5 minutes): {{mvn -f playground-jar/pom.xml exec:exec -Druntime=300}} # Stop {{node1}} # Stop {{node2}} # Stop {{node3}} # Start {{node1}} (see above) again # observe {{node3}} in the list of available node, see: {{INFO (ThreadPoolTaskExecutor-5) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'}} > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Jörg Bäsner (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Jörg Bäsner updated WFLY-11682: ------------------------------- Attachment: playground.zip > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3613) Error testing a rule scenario with a Map

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-3613?page=com.atlassian.jira.plugi... ] Daniele Zonca updated DROOLS-3613: ---------------------------------- Issue Type: Bug (was: Task) > Error testing a rule scenario with a Map > ---------------------------------------- > > Key: DROOLS-3613 > URL: https://issues.jboss.org/browse/DROOLS-3613 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Gabriele Cardosi > Priority: Major > Labels: ScenarioSimulation > > Fix serialization format from Map to string -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3613) Error testing a rule scenario with a Map

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-3613: ------------------------------------- Summary: Error testing a rule scenario with a Map Key: DROOLS-3613 URL: https://issues.jboss.org/browse/DROOLS-3613 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Daniele Zonca Assignee: Gabriele Cardosi Fix serialization format from Map to string -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Jörg Bäsner (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Jörg Bäsner updated WFLY-11682: ------------------------------- Description: This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. As long as all nodes are up and running the client is calling EJBs in a balanced way. When node1 is shut down, the client get the notification below: {code}... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) ... {code} Then node2 is shut down. Again the client get the information, see: {code} ... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) ... {code} Finally node3 is being shut down. Now the client only get the following information: {code} ... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground ... {code} This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. >From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: {code} ... INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' ... {code} was: This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. As long as all nodes are up and running the client is calling EJBs in a balanced way. When node1 is shut down, the client get the notification below: {code}... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) ... {code} Then node2 is shut down. Again the client get the information, see: {code} ... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) ... {code} Finally node3 is being shut down. Now the client only get the following information: {code} ... DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground ... {code} This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. >From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: ... INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.LBClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019