[JBoss JIRA] (WFLY-11319) Balancer keeps routing requests to workers in common load balancing group even when this group was disabled
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-11319?page=com.atlassian.jira.plugin... ]
Jan Kašík closed WFLY-11319.
----------------------------
Resolution: Explained
I misunderstood the concept.
> Balancer keeps routing requests to workers in common load balancing group even when this group was disabled
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11319
> URL: https://issues.jboss.org/browse/WFLY-11319
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 15.0.0.Beta1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Major
>
> When disabling nodes in common load balancing group, their contexts statuses became "disabled", however, balancer keeps routing requests to nodes in this group. Console after disable operation has been called:
> {noformat}
> {
> "outcome" => "success",
> "result" => {
> "advertise-frequency" => 10000,
> "advertise-path" => "/",
> "advertise-protocol" => "http",
> "advertise-socket-binding" => "modcluster",
> "broken-node-timeout" => 60000,
> "cached-connections-per-thread" => 40,
> "connection-idle-timeout" => 60,
> "connections-per-thread" => 40,
> "enable-http2" => false,
> "failover-strategy" => "LOAD_BALANCED",
> "health-check-interval" => 10000,
> "http2-enable-push" => true,
> "http2-header-table-size" => 4096,
> "http2-initial-window-size" => 65535,
> "http2-max-concurrent-streams" => undefined,
> "http2-max-frame-size" => 16384,
> "http2-max-header-list-size" => undefined,
> "management-access-predicate" => undefined,
> "management-socket-binding" => "http",
> "max-ajp-packet-size" => 8192,
> "max-request-time" => -1,
> "max-retries" => 1L,
> "request-queue-size" => 1000,
> "security-key" => undefined,
> "security-realm" => undefined,
> "ssl-context" => undefined,
> "use-alias" => false,
> "worker" => "default",
> "balancer" => {"mycluster" => {
> "max-attempts" => 1,
> "sticky-session" => true,
> "sticky-session-cookie" => "JSESSIONID",
> "sticky-session-force" => false,
> "sticky-session-path" => undefined,
> "sticky-session-remove" => false,
> "wait-worker" => 0,
> "load-balancing-group" => undefined,
> "node" => {
> "wildfly-15.0.0.Alpha1-SNAPSHOT-3" => {
> "aliases" => [
> "default-host",
> "localhost"
> ],
> "cache-connections" => 40,
> "elected" => 3,
> "flush-packets" => false,
> "load" => 71,
> "load-balancing-group" => "groupTwo",
> "max-connections" => 40,
> "open-connections" => 5,
> "ping" => 10,
> "queue-new-requests" => true,
> "read" => 0L,
> "request-queue-size" => 1000,
> "status" => "NODE_UP",
> "timeout" => 0,
> "ttl" => 60L,
> "uri" => "ajp://172.17.0.2:8211/?#",
> "written" => 0L,
> "context" => {
> "/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> },
> "/" => {
> "requests" => 0,
> "status" => "disabled"
> },
> "/wildfly-services" => {
> "requests" => 0,
> "status" => "disabled"
> }
> }
> },
> "wildfly-15.0.0.Alpha1-SNAPSHOT-4" => {
> "aliases" => [
> "default-host",
> "localhost"
> ],
> "cache-connections" => 40,
> "elected" => 2,
> "flush-packets" => false,
> "load" => 70,
> "load-balancing-group" => "groupTwo",
> "max-connections" => 40,
> "open-connections" => 4,
> "ping" => 10,
> "queue-new-requests" => true,
> "read" => 0L,
> "request-queue-size" => 1000,
> "status" => "NODE_UP",
> "timeout" => 0,
> "ttl" => 60L,
> "uri" => "ajp://172.17.0.2:8312/?#",
> "written" => 0L,
> "context" => {
> "/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> },
> "/" => {
> "requests" => 0,
> "status" => "disabled"
> },
> "/wildfly-services" => {
> "requests" => 0,
> "status" => "disabled"
> }
> }
> },
> "wildfly-15.0.0.Alpha1-SNAPSHOT-1" => {
> "aliases" => [
> "default-host",
> "localhost"
> ],
> "cache-connections" => 40,
> "elected" => 0,
> "flush-packets" => false,
> "load" => 70,
> "load-balancing-group" => "groupOne",
> "max-connections" => 40,
> "open-connections" => 4,
> "ping" => 10,
> "queue-new-requests" => true,
> "read" => 0L,
> "request-queue-size" => 1000,
> "status" => "NODE_UP",
> "timeout" => 0,
> "ttl" => 60L,
> "uri" => "ajp://172.17.0.2:8009/?#",
> "written" => 0L,
> "context" => {
> "/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> },
> "/" => {
> "requests" => 0,
> "status" => "enabled"
> },
> "/wildfly-services" => {
> "requests" => 0,
> "status" => "enabled"
> }
> }
> },
> "wildfly-15.0.0.Alpha1-SNAPSHOT-2" => {
> "aliases" => [
> "default-host",
> "localhost"
> ],
> "cache-connections" => 40,
> "elected" => 0,
> "flush-packets" => false,
> "load" => 70,
> "load-balancing-group" => "groupOne",
> "max-connections" => 40,
> "open-connections" => 5,
> "ping" => 10,
> "queue-new-requests" => true,
> "read" => 0L,
> "request-queue-size" => 1000,
> "status" => "NODE_UP",
> "timeout" => 0,
> "ttl" => 60L,
> "uri" => "ajp://172.17.0.2:8110/?#",
> "written" => 0L,
> "context" => {
> "/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> },
> "/" => {
> "requests" => 0,
> "status" => "enabled"
> },
> "/wildfly-services" => {
> "requests" => 0,
> "status" => "enabled"
> }
> }
> }
> }
> }}
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-2747) [DMN Designer] Support table header cell selection
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-2747?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-2747:
---------------------------------
Epic Status: Done (was: To Do)
> [DMN Designer] Support table header cell selection
> --------------------------------------------------
>
> Key: DROOLS-2747
> URL: https://issues.jboss.org/browse/DROOLS-2747
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.14.0.Final
>
> Attachments: Screenshot from 2018-03-20 08-59-39.png, Screenshot from 2018-03-20 09-20-04.png
>
>
> The decision table header cell does not support highlight / selection feature, see:
> !Screenshot from 2018-03-20 08-59-39.png|thumbnail!
> In contrast context entry name cell support this:
> !Screenshot from 2018-03-20 09-20-04.png|thumbnail!
> The outline should be consistent, i.e. blue rectangle should be rendered regardless of the selected cell type (data vs. header).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11059) Clients do not failover to backup even it if backup started and keep retrying connection
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11059?page=com.atlassian.jira.plugin... ]
Miroslav Novak resolved WFLY-11059.
-----------------------------------
Resolution: Done
Based on information from AMQ team (ENTMQBR-1818) this issue is no longer present. Setting as resolved.
I've also started reproducer 50x times and did not hit the issue. In case that issue will be hit in the future jira will be re-opened.
> Clients do not failover to backup even it if backup started and keep retrying connection
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-11059
> URL: https://issues.jboss.org/browse/WFLY-11059
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Critical
> Attachments: NettyColocatedClusterFailoverTestCase.testFailbackClientAckQueueNIO.zip
>
>
> Test Scenario:
> * Start 2 servers in colocated topology with shared store
> * Start procuder and consumer sending/receiving messages to/from queue on 1st server(to live)
> * Kill 1st server and wait for backup on 2nd server to start
> * Clients failover to backup to 2nd server and wait for them to finish
> * Check that number of sent/received messages is the same
> Result:
> Sometimes happens that clients do not failover to backup to 2nd server and retry connection. I can see that backup on 2nd server started and created cluster with colocated live server but clients did not connect to it.
> Clients are retrying connection:
> {code}
> 07:32:16,676 Thread-36 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:794] Trying reconnection attempt 163/-1
> 07:32:16,676 Thread-39 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:446] Connector NettyConnector [host=rhel7-large-42748, port=5445, httpEnabled=fa
> lse, httpUpgradeEnabled=false, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] using native epoll
> 07:32:16,676 Thread-36 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1080] Trying to connect with connectorFactory = org.apache.activemq.artemis.co
> re.remoting.impl.netty.NettyConnectorFactory@6568a014, connectorConfig=TransportConfiguration(name=null, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&useNio=true
> &host=rhel7-large-42748&useNioGlobalWorkerPool=true&blockOnNonDurableSend=false&retryIntervalMultiplier=1-0&maxRetryInterval=2000&producerMaxRate=-1&blockOnDurableSend=true&connectionTTL=60000&compressLargeMessa
> ge=false&reconnectAttempts=-1&ignoreJTA=false&cacheLargeMessagesClient=false&scheduledThreadPoolMaxSize=5&useGlobalPools=true&callFailoverTimeout=60000&initialConnectAttempts=1&clientFailureCheckPeriod=30000&blo
> ckOnAcknowledge=true&consumerWindowSize=1048576&minLargeMessageSize=102400&finalizeChecks=false&autoGroup=false&threadPoolMaxSize=30&confirmationWindowSize=-1&transactionBatchSize=1048576&callTimeout=30000&preAc
> knowledge=false&enable1xPrefixes=true&cacheDestinations=false&connectionLoadBalancingPolicyClassName=org-apache-activemq-artemis-api-core-client-loadbalance-RoundRobinConnectionLoadBalancingPolicy&dupsOKBatchSiz
> e=1048576&incomingInterceptorList=&initialMessagePacketSize=1500&consumerMaxRate=-1&enableSharedClientID=true&HA=true&retryInterval=2000&factoryType=0&failoverOnInitialConnection=false&outgoingInterceptorList=&p
> roducerWindowSize=65536
> 07:32:16,676 Thread-39 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:600] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to rhel7-larg
> e-42748:5445
> 07:32:16,676 Thread-36 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:446] Connector NettyConnector [host=rhel7-large-42748, port=5445, httpEnabled=fa
> lse, httpUpgradeEnabled=false, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] using native epoll
> 07:32:16,676 Thread-38 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:794] Trying reconnection attempt 163/-1
> 07:32:16,676 Thread-38 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1080] Trying to connect with connectorFactory = org.apache.activemq.artemis.co
> re.remoting.impl.netty.NettyConnectorFactory@43d7f9fb, connectorConfig=TransportConfiguration(name=null, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=5445&useNio=true
> &host=rhel7-large-42748&useNioGlobalWorkerPool=true&blockOnNonDurableSend=false&retryIntervalMultiplier=1-0&maxRetryInterval=2000&producerMaxRate=-1&blockOnDurableSend=true&connectionTTL=60000&compressLargeMessa
> ge=false&reconnectAttempts=-1&ignoreJTA=false&cacheLargeMessagesClient=false&scheduledThreadPoolMaxSize=5&useGlobalPools=true&callFailoverTimeout=60000&initialConnectAttempts=1&clientFailureCheckPeriod=30000&blo
> ckOnAcknowledge=true&consumerWindowSize=1048576&minLargeMessageSize=102400&finalizeChecks=false&autoGroup=false&threadPoolMaxSize=30&confirmationWindowSize=-1&transactionBatchSize=1048576&callTimeout=30000&preAc
> knowledge=false&enable1xPrefixes=true&cacheDestinations=false&connectionLoadBalancingPolicyClassName=org-apache-activemq-artemis-api-core-client-loadbalance-RoundRobinConnectionLoadBalancingPolicy&dupsOKBatchSiz
> e=1048576&incomingInterceptorList=&initialMessagePacketSize=1500&consumerMaxRate=-1&enableSharedClientID=true&HA=true&retryInterval=2000&factoryType=0&failoverOnInitialConnection=false&outgoingInterceptorList=&p
> roducerWindowSize=65536
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFWIP-149) Destination not created on remote Artemis broker
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFWIP-149?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFWIP-149:
---------------------------------
Summary: Destination not created on remote Artemis broker (was: Destination not create on remote Artemis broker)
> Destination not created on remote Artemis broker
> ------------------------------------------------
>
> Key: WFWIP-149
> URL: https://issues.jboss.org/browse/WFWIP-149
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> JMS Destination is not created on remote broker/cluster if activemq-ra resource adapter is configured to connect to it.
> Test scenario:
> * Start two servers in Artemis cluster (node-1, node-3)
> * Start one more server (node-2) which has configured activemq-ra with initial connectors to remote cluster (node-1, node-3)
> * Deploy MDB with to node-2 with:
> {code}
> @JMSConnectionFactoryDefinition(
> name="java:/jms/myRemoteJmsCf",
> resourceAdapter="activemq-ra")
> @JMSDestinationDefinitions({
> @JMSDestinationDefinition(
> name = "java:/jms/queue/myRemoteOutQueue",
> interfaceName = "javax.jms.Queue",
> resourceAdapter = "activemq-ra",
> destinationName = "myRemoteOutQueue"),
> @JMSDestinationDefinition(
> name = "java:/jms/queue/myRemoteInQueue",
> interfaceName = "javax.jms.Queue",
> resourceAdapter = "activemq-ra",
> destinationName = "myRemoteInQueue")
> })
> {code}
> ** MDB resends messages from myRemoteInQueue to myRemoteOutQueue (send using java:/jms/myRemoteJmsCf)
> * Deploy Servlet to node-2 which uses myRemoteJmsCf to send messages to myRemoteInQueue which are then processed by MDB and re-sent to myRemoteOutQueue
> Expected result: All messages will be in myRemoteOutQueue
> Actual result: No message was processed
> Investigation:
> Problem is that both of the queues were created on node-2 and not in remote artemis cluster (node-1,3)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months