[jira] [Work logged] (ARTEMIS-4652) Rollback of XAResource implementation should never return XA_RETRY
[ https://issues.apache.org/jira/browse/ARTEMIS-4652?focusedWorklogId=906167&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906167 ] ASF GitHub Bot logged work on ARTEMIS-4652: --- Author: ASF GitHub Bot Created on: 21/Feb/24 07:27 Start Date: 21/Feb/24 07:27 Worklog Time Spent: 10m Work Description: ehsavoie commented on code in PR #4828: URL: https://github.com/apache/activemq-artemis/pull/4828#discussion_r1497020205 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionImpl.java: ## @@ -1901,18 +1901,10 @@ public void rollback(final Xid xid) throws XAException { workDone = false; } catch (XAException xae) { throw xae; - } catch (ActiveMQException e) { - if (e.getType() == ActiveMQExceptionType.UNBLOCKED || e.getType() == ActiveMQExceptionType.CONNECTION_TIMEDOUT || e.getType() == ActiveMQExceptionType.SHUTDOWN_ERROR) { -// Unblocked on failover -throw new XAException(XAException.XA_RETRY); - } - - // This should never occur - XAException xaException = new XAException(XAException.XAER_RMFAIL); - xaException.initCause(e); - throw xaException; } catch (Throwable t) { - // This could occur if the TM interrupts the thread + if (logger.isTraceEnabled()) { +logger.trace("Rollback failed:: {}", convert(xid), t); + } XAException xaException = new XAException(XAException.XAER_RMFAIL); Review Comment: @clebertsuconic it comes from a MDB test failure in WildFly, maybe we should run the all those tests with the fix on. Issue Time Tracking --- Worklog Id: (was: 906167) Time Spent: 0.5h (was: 20m) > Rollback of XAResource implementation should never return XA_RETRY > -- > > Key: ARTEMIS-4652 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4652 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > According to [the XA > spec|https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf] {{XA_RETRY}} is > not a valid response from {{xa_rollback}}. We should return {{XAER_RMFAIL}} > instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4654) Misleading error message while connecting to host with underscore
[ https://issues.apache.org/jira/browse/ARTEMIS-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lauri Kimmel updated ARTEMIS-4654: -- Description: Underscore in hostname produces unexpected error message. See details below. It's problematic since # error message is misleading # hostname with underscore is valid for certain setups. I.e in Docker compose / swarm environments. # underscore in hostname works for different other client libraries. Tested with Postgres, InfluxDB, Redis — Code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local_host:61616"); factory.createConnection(); {code} produces output {code:java} WARN [org.apa.act.art.cor.client] (main) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.lang.IllegalArgumentException: port out of range:-1 at java.base/java.net.InetSocketAddress.checkPort(InetSocketAddress.java:152) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:233) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:874) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:866) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:848) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1212) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1333) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1253) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1496) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:1074) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:959) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:279) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:295) at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:709) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:284) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:279) ... {code} while code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local-host:61616"); factory.createConnection(); {code} produces output {code:java} ERROR [org.apa.act.art.cor.client] (main) AMQ214016: Failed to create netty connection: java.net.UnknownHostException: local-host at java.base/java.net.InetAddress$CachedAddresses.get(InetAddress.java:801) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153) at io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31) at io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106) at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206) at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:180) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:166) at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.ja
[jira] [Updated] (ARTEMIS-4654) Misleading error message while connecting to host with underscore
[ https://issues.apache.org/jira/browse/ARTEMIS-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lauri Kimmel updated ARTEMIS-4654: -- Description: Underscore in hostname produced unexpected error message. See details below. It's problematic since # error message is misleading # hostname with underscore is valid for certain setups. I.e in Docker compose / swarm environments. # underscore in hostname works for different other client libraries. Tested with Postgres, InfluxDB, Redis — Code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local_host:61616"); factory.createConnection(); {code} produces output {code:java} WARN [org.apa.act.art.cor.client] (main) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.lang.IllegalArgumentException: port out of range:-1 at java.base/java.net.InetSocketAddress.checkPort(InetSocketAddress.java:152) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:233) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:874) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:866) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:848) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1212) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1333) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1253) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1496) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:1074) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:959) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:279) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:295) at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:709) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:284) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:279) ... {code} while code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local-host:61616"); factory.createConnection(); {code} produces output {code:java} ERROR [org.apa.act.art.cor.client] (main) AMQ214016: Failed to create netty connection: java.net.UnknownHostException: local-host at java.base/java.net.InetAddress$CachedAddresses.get(InetAddress.java:801) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153) at io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31) at io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106) at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206) at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:180) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:166) at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.ja
[jira] [Updated] (ARTEMIS-4654) Misleading error message while connecting to host with underscore
[ https://issues.apache.org/jira/browse/ARTEMIS-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lauri Kimmel updated ARTEMIS-4654: -- Description: Underscore in hostname produced unexpected error message. See details below. It's problematic since # error message is misleading # hostname with underscore is valid for certain setups. I.e in Docker compose / swarm environments. # underscore in hostname works for different other client libraries. Tested with Postgres, InfluxDB, Redis — Code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local_host:61616"); factory.createConnection(); {code} produces output {code:java} [org.apa.act.art.cor.client] (main) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.lang.IllegalArgumentException: port out of range:-1 at java.base/java.net.InetSocketAddress.checkPort(InetSocketAddress.java:152) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:233) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:874) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:866) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:848) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1212) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1333) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1253) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1496) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:1074) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:959) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:279) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:295) at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:709) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:284) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:279) ... {code} while code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local-host:61616"); factory.createConnection(); {code} produces output {code:java} ERROR [org.apa.act.art.cor.client] (main) AMQ214016: Failed to create netty connection: java.net.UnknownHostException: local-host at java.base/java.net.InetAddress$CachedAddresses.get(InetAddress.java:801) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153) at io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31) at io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106) at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206) at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:180) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:166) at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
[jira] [Updated] (ARTEMIS-4654) Misleading error message while connecting to host with underscore
[ https://issues.apache.org/jira/browse/ARTEMIS-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lauri Kimmel updated ARTEMIS-4654: -- Description: Underscore in hostname produced unexpected error message. See details below. It's problematic since # error message is misleading # hostname with underscore is valid for certain setups. I.e in Docker compose / swarm environments. # underscore in hostname works for different other client libraries. Tested with Postgres, InfluxDB, Redis — Code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local_host:61616"); factory.createConnection(); {code} produces output {code:java} [org.apa.act.art.cor.client] (main) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.lang.IllegalArgumentException: port out of range:-1 at java.base/java.net.InetSocketAddress.checkPort(InetSocketAddress.java:152) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:233) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:874) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:866) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:848) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1212) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1333) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1253) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1496) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:1074) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:959) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:279) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:295) at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:709) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:284) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:279) ... {code} while code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local-host:61616"); factory.createConnection(); {code} produces output {code:java} ERROR [org.apa.act.art.cor.client] (main) AMQ214016: Failed to create netty connection: java.net.UnknownHostException: local-host at java.base/java.net.InetAddress$CachedAddresses.get(InetAddress.java:801) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153) at io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31) at io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106) at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206) at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:180) at io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:166) at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
[jira] [Created] (ARTEMIS-4654) Misleading error message while connecting to host with underscore
Lauri Kimmel created ARTEMIS-4654: - Summary: Misleading error message while connecting to host with underscore Key: ARTEMIS-4654 URL: https://issues.apache.org/jira/browse/ARTEMIS-4654 Project: ActiveMQ Artemis Issue Type: Bug Components: Configuration Affects Versions: 2.31.0 Reporter: Lauri Kimmel Underscore in hostname produced unexpected error message. See details below. It's problematic since # error message is misleading # hostname with underscore is valid for certain setups. I.e in Docker compose / swarm environments. # underscore in hostname works for different other client libraries. Tested with Postgres, InfluxDB, Redis --- Code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local_host:61616"); factory.createConnection(); {code} produces output {code:java} [org.apa.act.art.cor.client] (main) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.lang.IllegalArgumentException: port out of range:-1 at java.base/java.net.InetSocketAddress.checkPort(InetSocketAddress.java:152) at java.base/java.net.InetSocketAddress.(InetSocketAddress.java:233) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:874) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:866) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:848) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1212) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1333) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1253) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1496) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:1074) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:959) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:279) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:295) at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:709) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:865) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:284) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:279) ... {code} while code {code:java} ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://local-host:61616"); factory.createConnection(); {code} produces output {code:java} ERROR [org.apa.act.art.cor.client] (main) AMQ214016: Failed to create netty connection: java.net.UnknownHostException: local-host at java.base/java.net.InetAddress$CachedAddresses.get(InetAddress.java:801) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301) at java.base/java.net.InetAddress.getByName(InetAddress.java:1251) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156) at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153) at io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61) at io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55) at io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31) at io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106) at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206) at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46) at io.netty.
[jira] [Work logged] (ARTEMIS-4652) Rollback of XAResource implementation should never return XA_RETRY
[ https://issues.apache.org/jira/browse/ARTEMIS-4652?focusedWorklogId=906127&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906127 ] ASF GitHub Bot logged work on ARTEMIS-4652: --- Author: ASF GitHub Bot Created on: 21/Feb/24 02:41 Start Date: 21/Feb/24 02:41 Worklog Time Spent: 10m Work Description: clebertsuconic commented on code in PR #4828: URL: https://github.com/apache/activemq-artemis/pull/4828#discussion_r1496803798 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionImpl.java: ## @@ -1901,18 +1901,10 @@ public void rollback(final Xid xid) throws XAException { workDone = false; } catch (XAException xae) { throw xae; - } catch (ActiveMQException e) { - if (e.getType() == ActiveMQExceptionType.UNBLOCKED || e.getType() == ActiveMQExceptionType.CONNECTION_TIMEDOUT || e.getType() == ActiveMQExceptionType.SHUTDOWN_ERROR) { -// Unblocked on failover -throw new XAException(XAException.XA_RETRY); - } - - // This should never occur - XAException xaException = new XAException(XAException.XAER_RMFAIL); - xaException.initCause(e); - throw xaException; } catch (Throwable t) { - // This could occur if the TM interrupts the thread + if (logger.isTraceEnabled()) { +logger.trace("Rollback failed:: {}", convert(xid), t); + } XAException xaException = new XAException(XAException.XAER_RMFAIL); Review Comment: would the TM retry the rollback in such event? Did this request come from Wildly / @ehsavoie ? My biggest concern in such changes is the integration with MDBs as I remember having massive headaches with MDB / XA tests back then which I don't want to go back :) Issue Time Tracking --- Worklog Id: (was: 906127) Time Spent: 20m (was: 10m) > Rollback of XAResource implementation should never return XA_RETRY > -- > > Key: ARTEMIS-4652 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4652 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > According to [the XA > spec|https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf] {{XA_RETRY}} is > not a valid response from {{xa_rollback}}. We should return {{XAER_RMFAIL}} > instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4653) AMQP Federation should apply queue consumer filters for demand
[ https://issues.apache.org/jira/browse/ARTEMIS-4653?focusedWorklogId=906111&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906111 ] ASF GitHub Bot logged work on ARTEMIS-4653: --- Author: ASF GitHub Bot Created on: 20/Feb/24 23:34 Start Date: 20/Feb/24 23:34 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4829: URL: https://github.com/apache/activemq-artemis/pull/4829 …filters When Queue consumers attach with filters use those instead of the Queue filter to filter the messages that are federated to avoid stranding of messages on the local broker. This will result in multiple federation consumers if the various attached local consumers all use different filters but does keop unwanted messages on the remote so that consumers there can consume those. Issue Time Tracking --- Worklog Id: (was: 906111) Remaining Estimate: 0h Time Spent: 10m > AMQP Federation should apply queue consumer filters for demand > -- > > Key: ARTEMIS-4653 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4653 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.32.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.33.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For Queue federation the federation consumers should apply a consumer defined > filter over the Queue defined filter to avoid pulling message across the link > that won't be deliverable. Add options for disabling this and also disabling > per consumer consumer priority tracking to allow for reduction of federation > links when desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4653) AMQP Federation should apply queue consumer filters for demand
Timothy A. Bish created ARTEMIS-4653: Summary: AMQP Federation should apply queue consumer filters for demand Key: ARTEMIS-4653 URL: https://issues.apache.org/jira/browse/ARTEMIS-4653 Project: ActiveMQ Artemis Issue Type: Improvement Components: AMQP Affects Versions: 2.32.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish Fix For: 2.33.0 For Queue federation the federation consumers should apply a consumer defined filter over the Queue defined filter to avoid pulling message across the link that won't be deliverable. Add options for disabling this and also disabling per consumer consumer priority tracking to allow for reduction of federation links when desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4652) Rollback of XAResource implementation should never return XA_RETRY
[ https://issues.apache.org/jira/browse/ARTEMIS-4652?focusedWorklogId=906096&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906096 ] ASF GitHub Bot logged work on ARTEMIS-4652: --- Author: ASF GitHub Bot Created on: 20/Feb/24 21:24 Start Date: 20/Feb/24 21:24 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4828: URL: https://github.com/apache/activemq-artemis/pull/4828 This fix was based on static analysis of the code and inspection of the XA specification. There is no test associated with it due to the difficult nature in reproducing the failure. This code has been essentially the same for a decade and only now have there been any reports of it actually sending back the wrong XA code. Issue Time Tracking --- Worklog Id: (was: 906096) Remaining Estimate: 0h Time Spent: 10m > Rollback of XAResource implementation should never return XA_RETRY > -- > > Key: ARTEMIS-4652 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4652 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > According to [the XA > spec|https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf] {{XA_RETRY}} is > not a valid response from {{xa_rollback}}. We should return {{XAER_RMFAIL}} > instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4652) Rollback of XAResource implementation should never return XA_RETRY
Justin Bertram created ARTEMIS-4652: --- Summary: Rollback of XAResource implementation should never return XA_RETRY Key: ARTEMIS-4652 URL: https://issues.apache.org/jira/browse/ARTEMIS-4652 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram According to [the XA spec|https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf] {{XA_RETRY}} is not a valid response from {{xa_rollback}}. We should return {{XAER_RMFAIL}} instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4646) Unacknowledged MQTT message ID is reused after ID generator wraparound
[ https://issues.apache.org/jira/browse/ARTEMIS-4646?focusedWorklogId=906093&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906093 ] ASF GitHub Bot logged work on ARTEMIS-4646: --- Author: ASF GitHub Bot Created on: 20/Feb/24 21:06 Start Date: 20/Feb/24 21:06 Worklog Time Spent: 10m Work Description: thezbyg commented on code in PR #4823: URL: https://github.com/apache/activemq-artemis/pull/4823#discussion_r1496507334 ## tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt/MQTTTest.java: ## @@ -447,6 +447,59 @@ public void testSendMoreThanUniqueId() throws Exception { publisher.disconnect(); } + @Ignore + @Test(timeout = 600 * 1000) + public void testNoMessageIdReuseBeforeAcknowledgment() throws Exception { Review Comment: Fixed test by using two initial messages. Previously it would not fail as first message had ID 1 and first ID after wraparound was 2. Issue Time Tracking --- Worklog Id: (was: 906093) Time Spent: 1h (was: 50m) > Unacknowledged MQTT message ID is reused after ID generator wraparound > -- > > Key: ARTEMIS-4646 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4646 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Reporter: Albertas Vyšniauskas >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Hello, > MQTT message IDs are currently generated by incrementing *ids* variable in > *{color:#00}{color:#00}OutboundStore{color}{color}* class and do not > perform any additional checks before trusting that it is unique. This works > great until one or more MQTT messages are not acknowledged in timely manner > while receiving and acknowledging other messages. A different message with > the same ID will be sent after 32767 additional messages are received and > acknowledged. > There are also more issues with MQTT message ID generation: > # *AtomicInteger* is used for *ids* variable, but all accesses and > modifications are done in synchronized context, so there is no need for it to > be atomic. > # Maximum allowed *ids* value before wraparound is {*}Short.MAX_VALUE{*}, > but MQTT protocol allows values in the range of 1 to 65535 (all unsigned > short values except 0). > # Wraparound is done to value 1 and is immediately incremented thus skipping > message ID 1 and using 2 as first ID after wraparound. > # There is a harmless but wrong attempt to remove from *mqttToServerIds* > hash map by non-MQTT message ID in the following code: > \{_}mqttToServerIds.remove(p.getA());{_}. It is harmless because _p.getA()_ > returns *Long* value and will never match any key in *mqttToServerIds* hash > map which uses *Integer* keys.{*}{*} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4646) Unacknowledged MQTT message ID is reused after ID generator wraparound
[ https://issues.apache.org/jira/browse/ARTEMIS-4646?focusedWorklogId=906092&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906092 ] ASF GitHub Bot logged work on ARTEMIS-4646: --- Author: ASF GitHub Bot Created on: 20/Feb/24 21:02 Start Date: 20/Feb/24 21:02 Worklog Time Spent: 10m Work Description: thezbyg commented on code in PR #4823: URL: https://github.com/apache/activemq-artemis/pull/4823#discussion_r1496502532 ## tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt/MQTTTest.java: ## @@ -447,6 +447,59 @@ public void testSendMoreThanUniqueId() throws Exception { publisher.disconnect(); } + @Ignore Review Comment: I noticed a similar ignored test **testSendMoreThanUniqueId** and assumed that this new test should also be ignored because it also takes a long time run. Issue Time Tracking --- Worklog Id: (was: 906092) Time Spent: 50m (was: 40m) > Unacknowledged MQTT message ID is reused after ID generator wraparound > -- > > Key: ARTEMIS-4646 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4646 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Reporter: Albertas Vyšniauskas >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Hello, > MQTT message IDs are currently generated by incrementing *ids* variable in > *{color:#00}{color:#00}OutboundStore{color}{color}* class and do not > perform any additional checks before trusting that it is unique. This works > great until one or more MQTT messages are not acknowledged in timely manner > while receiving and acknowledging other messages. A different message with > the same ID will be sent after 32767 additional messages are received and > acknowledged. > There are also more issues with MQTT message ID generation: > # *AtomicInteger* is used for *ids* variable, but all accesses and > modifications are done in synchronized context, so there is no need for it to > be atomic. > # Maximum allowed *ids* value before wraparound is {*}Short.MAX_VALUE{*}, > but MQTT protocol allows values in the range of 1 to 65535 (all unsigned > short values except 0). > # Wraparound is done to value 1 and is immediately incremented thus skipping > message ID 1 and using 2 as first ID after wraparound. > # There is a harmless but wrong attempt to remove from *mqttToServerIds* > hash map by non-MQTT message ID in the following code: > \{_}mqttToServerIds.remove(p.getA());{_}. It is harmless because _p.getA()_ > returns *Long* value and will never match any key in *mqttToServerIds* hash > map which uses *Integer* keys.{*}{*} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4582) add view and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?focusedWorklogId=905958&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-905958 ] ASF GitHub Bot logged work on ARTEMIS-4582: --- Author: ASF GitHub Bot Created on: 20/Feb/24 14:52 Start Date: 20/Feb/24 14:52 Worklog Time Spent: 10m Work Description: gtully commented on PR #4820: URL: https://github.com/apache/activemq-artemis/pull/4820#issuecomment-1954384492 > Couple of question... > > 1. One of the things that `management.xml` let you do was configure remote JMX connectivity. How do I do that with this? management.xml will remain, this will just replace the authorization section. > 2. One nice thing about `management.xml` is that you didn't have to muck around with system properties. Any chance this could be configured via `broker.xml` instead of `javax.management.builder.initial`? Perhaps a new `` block would be useful here. the system property is important because I want to guard the platform mbean server, and this is created on startup. Typically our logging causes it is be instantiated. When the platform mbean server is guarded and jolokia exposes it, the need for a jmx connector diminishes. With the management wrapper of the broker, we were late setting the guard in the past. > 3. There is a fair bit of documentation about `management.xml` in `management.adoc`. Could you provide something analogous (or even more comprehensive) for this? A few simple use-cases with corresponding configuration would go a long way in helping users & developers understand how it works. sure. it is considerably simpler, with a mapping from objectName to address, and methods split into update or view permissions. > 4. The existing default `management.xml` has recommended settings (e.g. read-only access to non-Artemis MBeans). I think we should have something similar for this as well. Is that possible? that is a good idea, one thing that may get in the way is the default # security-settings-match. that will be applicable to jmx too but won't typically have the view role. but a security-settings-match jmx.# view role would do it. Issue Time Tracking --- Worklog Id: (was: 905958) Time Spent: 0.5h (was: 20m) > add view and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > update for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4651) Performance improvements on Mirror and Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-4651?focusedWorklogId=905949&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-905949 ] ASF GitHub Bot logged work on ARTEMIS-4651: --- Author: ASF GitHub Bot Created on: 20/Feb/24 13:55 Start Date: 20/Feb/24 13:55 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4827: URL: https://github.com/apache/activemq-artemis/pull/4827 As part of this PR, I am also including a little PWD command, that I used to test this manually. I would have many terminal windows open, and not knowing which terminal was connected at which server's. So PWD helped me a lot. Issue Time Tracking --- Worklog Id: (was: 905949) Remaining Estimate: 0h Time Spent: 10m > Performance improvements on Mirror and Paging > - > > Key: ARTEMIS-4651 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4651 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.33.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Before this change, sends were not paged at the SNF. They are now copied. > I also added a different scheme for retrying messages in a batches. A > collection with pending IDs is created and a few retries are performed at > different levels. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4651) Performance improvements on Mirror and Paging
Clebert Suconic created ARTEMIS-4651: Summary: Performance improvements on Mirror and Paging Key: ARTEMIS-4651 URL: https://issues.apache.org/jira/browse/ARTEMIS-4651 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.33.0 Before this change, sends were not paged at the SNF. They are now copied. I also added a different scheme for retrying messages in a batches. A collection with pending IDs is created and a few retries are performed at different levels. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4650) CLI command PWD showing current folders.
Clebert Suconic created ARTEMIS-4650: Summary: CLI command PWD showing current folders. Key: ARTEMIS-4650 URL: https://issues.apache.org/jira/browse/ARTEMIS-4650 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Clebert Suconic Fix For: 2.33.0 on my test workflow, I will in many occasions have many terminals open, with CLI terminals. After some time I won't know which server is the CLI connected with. and I will find myself typing pwd all the time as it's my mental model to figure ou where I'm at at the terminal windows. So, I decided to just create a command pwd, that will show the current folder, home folder and artemis instance in the terminal. I have been using and it's been very helpful to me.. a little tool that helped me with my own workflow. -- This message was sent by Atlassian Jira (v8.20.10#820010)