April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2404) Better configuration sanity checks

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2404?page=com.atlassian.jira.plugin... ] Bela Ban deleted JGRP-2404: --------------------------- > Better configuration sanity checks > ---------------------------------- > > Key: JGRP-2404 > URL: https://issues.redhat.com/browse/JGRP-2404 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > > Investigate whether more sanity checks can be applied to a configuration, e.g. missing UNICAST3 when TCP is configured etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2404) Better configuration sanity checks

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2404?page=com.atlassian.jira.plugin... ] Bela Ban closed JGRP-2404. -------------------------- > Better configuration sanity checks > ---------------------------------- > > Key: JGRP-2404 > URL: https://issues.redhat.com/browse/JGRP-2404 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.2, 5.0.0.Alpha4 > > > Investigate whether more sanity checks can be applied to a configuration, e.g. missing UNICAST3 when TCP is configured etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty reassigned WFLY-11442: ------------------------------------------ Assignee: Ranabir Chakraborty (was: Yeray Borges Santana) > Remove unused dependencies from org.jboss.as.ejb3 > ------------------------------------------------- > > Key: WFLY-11442 > URL: https://issues.redhat.com/browse/WFLY-11442 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Yeray Borges Santana > Assignee: Ranabir Chakraborty > Priority: Major > > Initial analisys checking only first level dependencies from the resource exposed by {{org.jboss.as.ejb3}} shows that these dependencies are being unused: > * org.jboss.jts > * org.wildfly.security.elytron-web.undertow-server > * org.jboss.as.weld > * org.wildfly.clustering.marshalling.spi > * org.wildfly.clustering.marshalling.api > * org.wildfly.client.config > * org.hibernate > The task here is verify that they are not used by any other machanism besides of being a first level dependency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2463: -------------------------------- {quote} I now have another theory: each TransferQueueBundler.run() iteration drains the entire contents of the queue into remove_queue, then tries to send the messages one by one. If there's an exception (e.g. java.net.ConnectException) sending any of those messages, it's only caught at the end of the iteration, and the next iteration drops all the unsent messages with removed_queue.clear(). {quote} No, that's not true: {{sendBundledMessages()}} will never throw an exception, as {{sendSingleMessage()}} and {{sendMessageList()}} catch (and log) all exceptions. > TransferQueueBundler: Message to stopped node blocks the bundler thread > ----------------------------------------------------------------------- > > Key: JGRP-2463 > URL: https://issues.redhat.com/browse/JGRP-2463 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination. > One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s). > {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message. > I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ] Dan Berindei commented on JGRP-2463: ------------------------------------ > The log snippet below shows that the connection attempt to the left member takes 4ms, so this should not be an issue: Oops, I should have checked the logs! I was convinced there was no ICMP error message in their test because they're killing the container, not just the server process. I now have another theory: each {{TransferQueueBundler.run()}} iteration drains the entire contents of the queue into {{remove_queue}}, then tries to send the messages one by one. If there's an exception (e.g. {{java.net.ConnectException}}) sending any of those messages, it's only caught at the end of the iteration, and the next iteration drops all the unsent messages with {{removed_queue.clear()}}. Since {{UNICAST3}} resends the last message to the missing node every {{UNICAST3.xmit_interval}} ms, some messages could be dropped more than once, leading to total latencies much higher than {{UNICAST3.xmit_interval}}. > Can this be reproduced? I assume the failure can be reproduced by the KeyCloak team, although they haven't added any more comments to KEYCLOAK-13310 > We could experiment with a bundler that has 1 queue for destination (and 1 associated thread dequeuing), and RED dropping messages before/when the queue gets full. However, this is too complicated a change... That's what I had in mind, in fact adding a comment to JGRP-2462 was my main motivation to open this JIRA :) > I think we should use TCP_NIO2 for scenarios in which TCP writes can block. I guess I should move JGRP-2108 up... wdyt? +100 > TransferQueueBundler: Message to stopped node blocks the bundler thread > ----------------------------------------------------------------------- > > Key: JGRP-2463 > URL: https://issues.redhat.com/browse/JGRP-2463 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination. > One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s). > {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message. > I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1107) Update prepare-e2e-tests-env.sh and prepare-ui-tests-env.sh to be less verbose

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1107: ------------------------------------ Summary: Update prepare-e2e-tests-env.sh and prepare-ui-tests-env.sh to be less verbose Key: SWSQE-1107 URL: https://issues.redhat.com/browse/SWSQE-1107 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta It produces very long output containing lot of: Cloning into '/home/jenkins/agent/workspace/run-kiali-e2e-tests/kiali'... Checking out files: 42% (3633/8645) Checking out files: 43% (3718/8645) Checking out files: 44% (3804/8645) Checking out files: 45% (3891/8645) Checking out files: 46% (3977/8645) Checking out files: 47% (4064/8645) Checking out files: 48% (4150/8645) From https://github.com/kiali/kiali * [new ref] refs/pull/1/head -> origin/pr/1/head * [new ref] refs/pull/1/merge -> origin/pr/1/merge * [new ref] refs/pull/10/head -> origin/pr/10/head * [new ref] refs/pull/10/merge -> origin/pr/10/merge * [new ref] refs/pull/100/head -> origin/pr/100/head * [new ref] refs/pull/1000/head -> origin/pr/1000/head * [new ref] refs/pull/1001/head -> origin/pr/1001/head * [new ref] refs/pull/1002/head -> origin/pr/1002/head * [new ref] refs/pull/1003/head -> origin/pr/1003/head * [new ref] refs/pull/1004/head -> origin/pr/1004/head * [new ref] refs/pull/1005/head -> origin/pr/1005/head * [new ref] refs/pull/1009/head -> origin/pr/1009/head * [new ref] refs/pull/101/head -> origin/pr/101/head * [new ref] refs/pull/1010/head -> origin/pr/1010/head * [new ref] refs/pull/1011/head -> origin/pr/1011/head * [new ref] refs/pull/1012/head -> origin/pr/1012/head * [new ref] refs/pull/1013/head -> origin/pr/1013/head * [new ref] refs/pull/1014/head -> origin/pr/1014/head * [new ref] refs/pull/1015/head -> origin/pr/1015/head * [new ref] refs/pull/1016/head -> origin/pr/1016/head -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4898) Bump the kernel management API version to 13.0.0 and the xsd to 13.0

by Jeff Mesnil (Jira)

Jeff Mesnil created WFCORE-4898: ----------------------------------- Summary: Bump the kernel management API version to 13.0.0 and the xsd to 13.0 Key: WFCORE-4898 URL: https://issues.redhat.com/browse/WFCORE-4898 Project: WildFly Core Issue Type: Task Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 7.0.0.Alpha1, 7.0.0.Final We know there are going to be API changes in WF Core 7, so we need to get the API version bumped so that when those changes happen appropriate transformers can be written to transform to the previous version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2463: -------------------------------- Note that the new leave handling (JGRP-2372) should help here, too. This was implemented in 4.1.5. > TransferQueueBundler: Message to stopped node blocks the bundler thread > ----------------------------------------------------------------------- > > Key: JGRP-2463 > URL: https://issues.redhat.com/browse/JGRP-2463 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination. > One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s). > {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message. > I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-11442: --------------------------------------------- Hello [~rchakrab], yes go ahead, thanks!. As usual, please before removing any dependency, review if they are no longer used, these sort of issues are old and code could have changed since I checked the dependencies. Thank you ! > Remove unused dependencies from org.jboss.as.ejb3 > ------------------------------------------------- > > Key: WFLY-11442 > URL: https://issues.redhat.com/browse/WFLY-11442 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > Initial analisys checking only first level dependencies from the resource exposed by {{org.jboss.as.ejb3}} shows that these dependencies are being unused: > * org.jboss.jts > * org.wildfly.security.elytron-web.undertow-server > * org.jboss.as.weld > * org.wildfly.clustering.marshalling.spi > * org.wildfly.clustering.marshalling.api > * org.wildfly.client.config > * org.hibernate > The task here is verify that they are not used by any other machanism besides of being a first level dependency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2463: -------------------------------- The log snippet below shows that the connection attempt to the left member takes 4ms, so this should not be an issue: {noformat} 12:26:31,350 TRACE [org.jgroups.protocols.TCP] (TQ-Bundler-8,ejb,52845618f899) 192.168.64.3:7600: connecting to 192.168.64.2:7600 12:26:31,354 TRACE [org.jgroups.protocols.TCP] (TQ-Bundler-8,ejb,52845618f899) 192.168.64.3:7600: failed connecting to 192.168.64.2:7600: java.net.ConnectException: Connection refused (Connection refused) {noformat} > TransferQueueBundler: Message to stopped node blocks the bundler thread > ----------------------------------------------------------------------- > > Key: JGRP-2463 > URL: https://issues.redhat.com/browse/JGRP-2463 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination. > One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s). > {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message. > I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 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 April 2020