April 2020 - jboss-jira - Jboss List Archives

[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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2108) TCP_NIO2: make default

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2108?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2108: --------------------------- Fix Version/s: 5.1 (was: 5.2) > TCP_NIO2: make default > ---------------------- > > Key: JGRP-2108 > URL: https://issues.redhat.com/browse/JGRP-2108 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > This requires the following things: > * performance of {{TCP_NIO2}} must be better than {{TCP}} > * (possibly) use multiple selectors: each selector handles only a max number of connections; create more selectors when the number of connections per selector exceeds a certain value > * (possibly) get rid of the reader thread and let the above selector do the read (the write is already done by the selector thread) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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: -------------------------------- Hi [~dan.berindei] Can this be reproduced? Establishing a connection to a port on which no process is listening will result in an ICMP error message back to the sender, and the connection will be closed immediately, so this should not be an issue. This scenario _can_ occur when: * The receiver doesn't read messages off of the TCP socket -> the TCP send-window at the sender will become 0 and the sender will block * The receiver is suspended ({{CTRL-Z}} or {{kill -SIGTSTP PID}}); this ends up being the same scenario as above 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... I think we should use {{TCP_NIO2}} for scenarios in which TCP writes can block. I guess I should move JGRP-2108 up... wdyt? > 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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5207) Binding in oopath works only on the first chuncks

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5207?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5207: -------------------------------- Summary: Binding in oopath works only on the first chuncks (was: Review oopath syntax and optimize performances where possible) > Binding in oopath works only on the first chuncks > ------------------------------------------------- > > Key: DROOLS-5207 > URL: https://issues.redhat.com/browse/DROOLS-5207 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13126) Refactor EJB client affinity processing

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13126?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-13126: -------------------------------------------- [~cfang] Is this issue still open ? Can you please provide the steps to reproduce the issue ? > Refactor EJB client affinity processing > --------------------------------------- > > Key: WFLY-13126 > URL: https://issues.redhat.com/browse/WFLY-13126 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Cheng Fang > Assignee: Richard Achmatowicz > Priority: Major > Labels: EAP-CD20 > > Refactor of jboss-ejb-client internal operation: change the way in which proxy affinity (an object that decides on which node invocation should be performed) is determined. Instead of calculating it on client side we would let server set the affinity when necessary and propagate it to the client. > This refactor is supposed to reduce the complexity of jboss-ejb-client code and as a result, make it significantly easier to maintain. Richard has prepared a comprehensive document describing the suggested modifications: https://mojo.redhat.com/docs/DOC-1204767 > Parallelly, the test suite has to be refactored to make it compatible with the new algorithm and to provide broad coverage of jboss-ejb-client operation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5207) Review oopath syntax and optimize performances where possible

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5207?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5207: -------------------------------- Issue Type: Bug (was: Task) > Review oopath syntax and optimize performances where possible > ------------------------------------------------------------- > > Key: DROOLS-5207 > URL: https://issues.redhat.com/browse/DROOLS-5207 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2461) Clustering can fail when re-adding an existing node using TCP_NIO2

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2461?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2461: -------------------------------- [~bjetal2003] Can I close this issue? > Clustering can fail when re-adding an existing node using TCP_NIO2 > ------------------------------------------------------------------ > > Key: JGRP-2461 > URL: https://issues.redhat.com/browse/JGRP-2461 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Robert Mitchell > Assignee: Bela Ban > Priority: Major > > When a node leaves a cluster and then later attempts to re-enter, a race condition can occur where the clustering fails to occur. Here is the sequence of events that seems to allow this to occur: > # The rejoining node must have a "higher" IP address than the current cluster coordinator. > # On the rejoin attempt, the coordinator sends a message to the rejoining node before the rejoining node sends to the coordinator using its prior address. I have seen this happen for two reasons: > ## UNICAST3 is resending messages (which often happens with the final LEAVE_RSP from the prior cluster membership because it apparently does not get acked before the connection closes) > ## TCPPING is sending a ping request to the cached prior address. > # The connection gets established. It will then be used by the rejoining node whenever communicating with the cluster coordinator. > # However, the cluster coordinator has this as the connection for the prior address. So the following happens whenever it wants to send a message to the rejoining node: > ## It will attempt to create a new connection. > ## The rejoining node will reject the connection as a redundant connection with its current connection taking precedence since it is coming from the same logical address as the "bad" connection. > Since the messages needed to find and join the cluster or merge the two clusters are all unicast messages, the rejoining node will never get them and not be able to join until something happens that causes the initial connection to get closed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020