[jira] [Commented] (ARTEMIS-4254) Transactional / Replication Soak Test
[ https://issues.apache.org/jira/browse/ARTEMIS-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719057#comment-17719057 ] ASF subversion and git services commented on ARTEMIS-4254: -- Commit f733cac08ff03a267c95bc81437f747df38f7932 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f733cac08f ] ARTEMIS-4254 Improving Transaction test with replication to use 3 nodes > Transactional / Replication Soak Test > - > > Key: ARTEMIS-4254 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4254 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > I recently developed a replication test under soak-test to validate producing > into a topic a failing over during the producers. > Even though I did not find anything wrong with the test, I am still > committing the test. (There is not enough testing, so... just one more to > ensure transaction and replication). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4254) Transactional / Replication Soak Test
[ https://issues.apache.org/jira/browse/ARTEMIS-4254?focusedWorklogId=860438=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860438 ] ASF GitHub Bot logged work on ARTEMIS-4254: --- Author: ASF GitHub Bot Created on: 03/May/23 20:51 Start Date: 03/May/23 20:51 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4457: URL: https://github.com/apache/activemq-artemis/pull/4457 Issue Time Tracking --- Worklog Id: (was: 860438) Time Spent: 0.5h (was: 20m) > Transactional / Replication Soak Test > - > > Key: ARTEMIS-4254 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4254 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > I recently developed a replication test under soak-test to validate producing > into a topic a failing over during the producers. > Even though I did not find anything wrong with the test, I am still > committing the test. (There is not enough testing, so... just one more to > ensure transaction and replication). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?focusedWorklogId=860416=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860416
]
ASF GitHub Bot logged work on ARTEMIS-4265:
---
Author: ASF GitHub Bot
Created on: 03/May/23 18:26
Start Date: 03/May/23 18:26
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4460:
URL:
https://github.com/apache/activemq-artemis/pull/4460#issuecomment-1533509949
@brusdev, I wasn't aware of that class. Based on your comment I took a look,
but I don't see how to customize the following files used by the broker:
- `management.xml`
- `artemis.profile`
- `artemis-users.properties`
- `artemis-roles.properties`
I need to set up a handful of different users in unique roles with access to
the console. Is this possible?
Issue Time Tracking
---
Worklog Id: (was: 860416)
Time Spent: 0.5h (was: 20m)
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4202) expand coverage of noCacheExceptions in LDAPLoginModule
[ https://issues.apache.org/jira/browse/ARTEMIS-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4202. - Fix Version/s: 2.29.0 Resolution: Fixed > expand coverage of noCacheExceptions in LDAPLoginModule > --- > > Key: ARTEMIS-4202 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4202 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Exceptions can happen outside of the existing coverage that can & should be > treated as no-cache exceptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4258) delayBeforeDispatch not working with OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4258. - Fix Version/s: 2.29.0 Resolution: Fixed > delayBeforeDispatch not working with OpenWire > - > > Key: ARTEMIS-4258 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4258 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4204) Connectors added via management are not durable
[ https://issues.apache.org/jira/browse/ARTEMIS-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4204. - Resolution: Fixed > Connectors added via management are not durable > --- > > Key: ARTEMIS-4204 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4204 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.28.0 >Reporter: Hartmut Horrer >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We are using the REST - Jolokia JMX Bridge interface to configure some > connectors (addConnector) and bridges (createBridge()). > After restarting the Artemis instance all these configurations are lost. Is > there any way to > get the static connectors and bridges durable by using the REST API? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4171) Potential large message file leak
[ https://issues.apache.org/jira/browse/ARTEMIS-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4171. - Fix Version/s: 2.29.0 Resolution: Fixed > Potential large message file leak > - > > Key: ARTEMIS-4171 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4171 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If an exception is thrown during the sending of a large message (e.g. from a > plugin) the large message file can be orphaned on disk. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4209) "User ID" in web console prefixed with "ID:ID:" for AMQP messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4209. - Fix Version/s: 2.29.0 Resolution: Fixed > "User ID" in web console prefixed with "ID:ID:" for AMQP messages > - > > Key: ARTEMIS-4209 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4209 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4210) Audit connection creation & destruction
[
https://issues.apache.org/jira/browse/ARTEMIS-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4210.
-
Fix Version/s: 2.29.0
Resolution: Fixed
> Audit connection creation & destruction
> ---
>
> Key: ARTEMIS-4210
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4210
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> I was looking into the audit logs offered by Artemis and I tried to
> connect/disconnect an MQTT client to/from the broker.
> While I found some logs at the MQTT connection (like this: 2023-03-16
> 11:05:28,291 [AUDIT](Thread-1
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1ad926d3))
> AMQ601715: User test==(Role_2)@127.0.0.1:51057 successfully authenticated),
> I was not able to find any log for tracing the MQTT disconection.
> I was wondering if it is possible, in one of the next releases, to add an
> audit log specific for the disconnection, since, from the Audit Log
> perspective, it would be useful to trace both the user login and his
> logout.{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4200) Allow configuring link-stealing behavior for MQTT
[
https://issues.apache.org/jira/browse/ARTEMIS-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4200:
Description:
The MQTT specifications define a behavior often referred to as "link stealing."
This means that whenever a new client connects with the same client ID as
another existing client then the existing client's session will be closed and
its network connection will be terminated.
In certain use-cases this behavior is not desired so it is configurable. The
URL parameter {{allowLinkStealing}} can be configured on the MQTT {{acceptor}}
to modify this behavior. By default {{allowLinkStealing}} is {{true}}. If it is
set to {{false}} then whenever a new client connects with the same client ID as
another existing client then the _new_ client's session will be closed and its
network connection will be terminated. In the case of MQTT 5 clients they will
receive a disconnect reason code of [{{0x80}} (i.e. "Unspecified
error")|https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901208].
> Allow configuring link-stealing behavior for MQTT
> -
>
> Key: ARTEMIS-4200
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4200
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
>
> The MQTT specifications define a behavior often referred to as "link
> stealing." This means that whenever a new client connects with the same
> client ID as another existing client then the existing client's session will
> be closed and its network connection will be terminated.
> In certain use-cases this behavior is not desired so it is configurable. The
> URL parameter {{allowLinkStealing}} can be configured on the MQTT
> {{acceptor}} to modify this behavior. By default {{allowLinkStealing}} is
> {{true}}. If it is set to {{false}} then whenever a new client connects with
> the same client ID as another existing client then the _new_ client's session
> will be closed and its network connection will be terminated. In the case of
> MQTT 5 clients they will receive a disconnect reason code of [{{0x80}} (i.e.
> "Unspecified
> error")|https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901208].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4200) Allow configuring link-stealing behavior for MQTT
[ https://issues.apache.org/jira/browse/ARTEMIS-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4200. - Fix Version/s: 2.29.0 Resolution: Fixed > Allow configuring link-stealing behavior for MQTT > - > > Key: ARTEMIS-4200 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4200 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4162) Support deleting addresses and queues without usage check
[ https://issues.apache.org/jira/browse/ARTEMIS-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4162. - Fix Version/s: 2.29.0 Resolution: Fixed > Support deleting addresses and queues without usage check > - > > Key: ARTEMIS-4162 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4162 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There are certain use-cases where addresses will be auto-created and never > have a direct binding created on them. Because of this they will never be > auto-deleted. If a large number of these addresses build up they will consume > a problematic amount of heap space. > One specific example of this use-case is an MQTT subscriber with a wild-card > subscription and a large number of MQTT producers sending one or two messages > a large number of different MQTT topics covered by the wild-card. Since > consumers are never created on any of these individual addresses they will > never be auto-deleted, but they will eventually consume a large amount of > heap. The only way to deal with these addresses is to manually delete them. > We should have a way to tell the address reaper to skip the usage check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4181) Make try-with-resources style consistent
[ https://issues.apache.org/jira/browse/ARTEMIS-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4181. - Fix Version/s: 2.29.0 Resolution: Fixed > Make try-with-resources style consistent > > > Key: ARTEMIS-4181 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4181 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > There are 872 instances of try-with-resources in the code-base and 151 of > those use more than 1 resource. These should all follow a consistent style - > 1 resource per line with no unnecessary semicolon at the end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4172) Sending large message via core skips plugins & audit logging
[ https://issues.apache.org/jira/browse/ARTEMIS-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4172. - Fix Version/s: 2.29.0 Resolution: Fixed > Sending large message via core skips plugins & audit logging > > > Key: ARTEMIS-4172 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4172 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4170) Remove redundant queue creation for OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4170. - Fix Version/s: 2.29.0 Resolution: Fixed > Remove redundant queue creation for OpenWire > > > Key: ARTEMIS-4170 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4170 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4150) Disable Log4j2 MBean by default
[ https://issues.apache.org/jira/browse/ARTEMIS-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4150. - Fix Version/s: 2.29.0 Resolution: Fixed > Disable Log4j2 MBean by default > --- > > Key: ARTEMIS-4150 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4150 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4153) Support "offline" Maven
[
https://issues.apache.org/jira/browse/ARTEMIS-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4153.
-
Fix Version/s: 2.29.0
Resolution: Fixed
> Support "offline" Maven
> ---
>
> Key: ARTEMIS-4153
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4153
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to run Maven in "offline" mode (e.g. {{mvn -o install}}) it is
> recommended to first run:
> {noformat}
> mvn dependency:go-offline{noformat}
> However, this currently results in an error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.3.0:go-offline
> (default-cli) on project artemis-commons:
> org.eclipse.aether.resolution.DependencyResolutionException:
> io.netty:netty-tcnative:jar:${os.detected.classifier}:2.0.54.Final was not
> found in https://remote.maven.repo during a previous attempt. This failure
> was cached in the local repository and resolution is not reattempted until
> the update interval of my-repository has elapsed or updates are forced ->
> [Help 1]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-1969) Document JCA RA
[ https://issues.apache.org/jira/browse/ARTEMIS-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram closed ARTEMIS-1969. --- Resolution: Duplicate > Document JCA RA > --- > > Key: ARTEMIS-1969 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1969 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > The JCA RA is mentioned in the documentation, but there is no description of > the activation configuration properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860414=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860414
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 18:02
Start Date: 03/May/23 18:02
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1184077685
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
Refactor done.
Issue Time Tracking
---
Worklog Id: (was: 860414)
Time Spent: 1h 10m (was: 1h)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860392=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860392
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 16:40
Start Date: 03/May/23 16:40
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1183943518
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
I'm going to rework this. It's not intuitive the way it's currently written.
Issue Time Tracking
---
Worklog Id: (was: 860392)
Time Spent: 1h (was: 50m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860386=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860386
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 16:26
Start Date: 03/May/23 16:26
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1183927642
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
Could the inversion be avoided if the `SecurityStoreImpl` would use
`ExceptionUtils.getRootCause(e)` to check that the root cause is
`NoCacheLoginException`?
Issue Time Tracking
---
Worklog Id: (was: 860386)
Time Spent: 50m (was: 40m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860373=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860373
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 15:39
Start Date: 03/May/23 15:39
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1183865073
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
Yes, the inversion is intentional as the `SecurityStoreImpl` will catch the
`NoCacheLoginException`, but the original exception still needs to be retained
for logging purposes.
Issue Time Tracking
---
Worklog Id: (was: 860373)
Time Spent: 40m (was: 0.5h)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860370=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860370
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 15:17
Start Date: 03/May/23 15:17
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1183835413
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
Are we inverting exception chain items on purpose?
Issue Time Tracking
---
Worklog Id: (was: 860370)
Time Spent: 20m (was: 10m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[
https://issues.apache.org/jira/browse/ARTEMIS-4267?focusedWorklogId=860371=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860371
]
ASF GitHub Bot logged work on ARTEMIS-4267:
---
Author: ASF GitHub Bot
Created on: 03/May/23 15:17
Start Date: 03/May/23 15:17
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4461:
URL: https://github.com/apache/activemq-artemis/pull/4461#discussion_r1183835413
##
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQJAASSecurityManager.java:
##
@@ -141,8 +141,10 @@ private Subject getAuthenticatedSubject(final String user,
try {
lc.login();
} catch (LoginException e) {
-Throwable rootCause = ExceptionUtil.getRootCause(e);
+Throwable rootCause = ExceptionUtils.getRootCause(e);
if (rootCause instanceof NoCacheLoginException) {
+ // preserve the original exception for logging
+ rootCause.initCause(e);
Review Comment:
Are you inverting exception chain items on purpose?
Issue Time Tracking
---
Worklog Id: (was: 860371)
Time Spent: 0.5h (was: 20m)
> Original exception lost for NoCacheLoginException
> -
>
> Key: ARTEMIS-4267
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4267
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When skipping the authentication cache the _original_ exception is not logged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (AMQ-8391) Consolidate to a single JAAS for jmx, messaging and web layers
[
https://issues.apache.org/jira/browse/AMQ-8391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718961#comment-17718961
]
Matt Pavlovich edited comment on AMQ-8391 at 5/3/23 3:12 PM:
-
JMX settings
{noformat}
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.login.config=activemq "
# ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF}/jmx.password"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF}/jmx.access"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.ssl=false "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote "
{noformat}
was (Author: mattrpav):
JMX settings
{noformat}
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.rmi.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.hostname=127.0.0.1 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.login.config=activemq "
# ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF}/jmx.password"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF}/jmx.access"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.ssl=false "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote "
{noformat}
> Consolidate to a single JAAS for jmx, messaging and web layers
> --
>
> Key: AMQ-8391
> URL: https://issues.apache.org/jira/browse/AMQ-8391
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
> Fix For: 5.19.0
>
>
> Currently, the default Apache ActiveMQ distribution has 3 user and group
> backends-- jmx, messaging and web.
> Update:
> 1. Migrate the jetty.xml to use the JAAS backend used for messaging
> 2. Add the jaasAuthentication to default activemq.xml (so it is explicitly
> visible)
> 3. Update the web-console servlet to permite access via 'web-console-role'
> 4. Update the api servlet to allow access using 'rest-role'
> 5. Add admin to the 'web-console-role' and 'rest-role' by default
> 6. Migrate jmx to use the 'activemq' realm
> 7. Create default jmx-readwrite-role and jmx-readonly-role roles in the
> conf/jmx.access file
> 8. Include the config breaking change in release notes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-8391) Consolidate to a single JAAS for jmx, messaging and web layers
[
https://issues.apache.org/jira/browse/AMQ-8391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718961#comment-17718961
]
Matt Pavlovich commented on AMQ-8391:
-
JMX settings
{noformat}
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.rmi.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.hostname=127.0.0.1 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.login.config=activemq "
# ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF}/jmx.password"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF}/jmx.access"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START
-Dcom.sun.management.jmxremote.ssl=false "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote "
{noformat}
> Consolidate to a single JAAS for jmx, messaging and web layers
> --
>
> Key: AMQ-8391
> URL: https://issues.apache.org/jira/browse/AMQ-8391
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
> Fix For: 5.19.0
>
>
> Currently, the default Apache ActiveMQ distribution has 3 user and group
> backends-- jmx, messaging and web.
> Update:
> 1. Migrate the jetty.xml to use the JAAS backend used for messaging
> 2. Add the jaasAuthentication to default activemq.xml (so it is explicitly
> visible)
> 3. Update the web-console servlet to permite access via 'web-console-role'
> 4. Update the api servlet to allow access using 'rest-role'
> 5. Add admin to the 'web-console-role' and 'rest-role' by default
> 6. Migrate jmx to use the 'activemq' realm
> 7. Create default jmx-readwrite-role and jmx-readonly-role roles in the
> conf/jmx.access file
> 8. Include the config breaking change in release notes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
[
https://issues.apache.org/jira/browse/ARTEMIS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Moritz updated ARTEMIS-4270:
Description:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening to *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M1
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2. When using
*consumer.receive()* it also works as expected.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
was:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M1
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2. When using
*consumer.receive()* it also works as expected.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
> Messages get lost when using multiple consumers with topic hierarchies
> --
>
> Key: ARTEMIS-4270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.24.0
>Reporter: Moritz
>Priority: Major
> Attachments: topic-hierarchies-bug.zip
>
>
> There is an issue when we have the following setup:
> * Shared durable consumer A listening to *news.#*
> * Shared durable consumer B listening to *news.europe.#*
> * Message M1 sent to *news.europe.sports*
> * Message M2 sent to *news.europe*
> Expected behavior:
> * A receives M1 and M2
> * B receives M1 and M2
> Actual behavior:
> * A receives M1 and M2
> * B receives M1
> This happens when it is run with a clean Artemis, i.e. without any previous
> data. If we run it a second time B receives M1 and M2. When using
> *consumer.receive()* it also works as expected.
>
> This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
> it so I chose the second version I've tested it for. The attached project
> showcases the bug where I simply adjusted the example
> {*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
> I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions
> concerning the topic not being multicast (already with the original example).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
[
https://issues.apache.org/jira/browse/ARTEMIS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Moritz updated ARTEMIS-4270:
Description:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M1
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2. When using
*consumer.receive()* it also works as expected.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
was:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M2
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2. When using
*consumer.receive()* it also works as expected.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
> Messages get lost when using multiple consumers with topic hierarchies
> --
>
> Key: ARTEMIS-4270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.24.0
>Reporter: Moritz
>Priority: Major
> Attachments: topic-hierarchies-bug.zip
>
>
> There is an issue when we have the following setup:
> * Shared durable consumer A listening to *news.#*
> * Shared durable consumer B listening tow *news.europe.#*
> * Message M1 sent to *news.europe.sports*
> * Message M2 sent to *news.europe*
> Expected behavior:
> * A receives M1 and M2
> * B receives M1 and M2
> Actual behavior:
> * A receives M1 and M2
> * B receives M1
> This happens when it is run with a clean Artemis, i.e. without any previous
> data. If we run it a second time B receives M1 and M2. When using
> *consumer.receive()* it also works as expected.
>
> This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
> it so I chose the second version I've tested it for. The attached project
> showcases the bug where I simply adjusted the example
> {*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
> I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions
> concerning the topic not being multicast (already with the original example).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
[
https://issues.apache.org/jira/browse/ARTEMIS-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Moritz updated ARTEMIS-4270:
Description:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M2
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2. When using
*consumer.receive()* it also works as expected.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
was:
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M2
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
> Messages get lost when using multiple consumers with topic hierarchies
> --
>
> Key: ARTEMIS-4270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.24.0
>Reporter: Moritz
>Priority: Major
> Attachments: topic-hierarchies-bug.zip
>
>
> There is an issue when we have the following setup:
> * Shared durable consumer A listening to *news.#*
> * Shared durable consumer B listening tow *news.europe.#*
> * Message M1 sent to *news.europe.sports*
> * Message M2 sent to *news.europe*
> Expected behavior:
> * A receives M1 and M2
> * B receives M1 and M2
> Actual behavior:
> * A receives M1 and M2
> * B receives M2
> This happens when it is run with a clean Artemis, i.e. without any previous
> data. If we run it a second time B receives M1 and M2. When using
> *consumer.receive()* it also works as expected.
>
> This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
> it so I chose the second version I've tested it for. The attached project
> showcases the bug where I simply adjusted the example
> {*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
> I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions
> concerning the topic not being multicast (already with the original example).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4270) Messages get lost when using multiple consumers with topic hierarchies
Moritz created ARTEMIS-4270:
---
Summary: Messages get lost when using multiple consumers with
topic hierarchies
Key: ARTEMIS-4270
URL: https://issues.apache.org/jira/browse/ARTEMIS-4270
Project: ActiveMQ Artemis
Issue Type: Bug
Components: JMS
Affects Versions: 2.24.0
Reporter: Moritz
Attachments: topic-hierarchies-bug.zip
There is an issue when we have the following setup:
* Shared durable consumer A listening to *news.#*
* Shared durable consumer B listening tow *news.europe.#*
* Message M1 sent to *news.europe.sports*
* Message M2 sent to *news.europe*
Expected behavior:
* A receives M1 and M2
* B receives M1 and M2
Actual behavior:
* A receives M1 and M2
* B receives M2
This happens when it is run with a clean Artemis, i.e. without any previous
data. If we run it a second time B receives M1 and M2.
This also affects at least version *3.0.0-SNAPSHOT* however I couldn't select
it so I chose the second version I've tested it for. The attached project
showcases the bug where I simply adjusted the example
{*}apache-artemis-3.0.0-SNAPSHOT/examples/features/standard/topic-hierarchies{*}.
I couldn't test it with 2.29.0-SNAPSHOT since I would get exceptions concerning
the topic not being multicast (already with the original example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=860363=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860363 ] ASF GitHub Bot logged work on ARTEMIS-4251: --- Author: ASF GitHub Bot Created on: 03/May/23 14:53 Start Date: 03/May/23 14:53 Worklog Time Spent: 10m Work Description: brusdev commented on PR #4447: URL: https://github.com/apache/activemq-artemis/pull/4447#issuecomment-1533179495 @gemmellr thanks for your review and suggestion Issue Time Tracking --- Worklog Id: (was: 860363) Time Spent: 2h (was: 1h 50m) > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=860362=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860362 ] ASF GitHub Bot logged work on ARTEMIS-4251: --- Author: ASF GitHub Bot Created on: 03/May/23 14:43 Start Date: 03/May/23 14:43 Worklog Time Spent: 10m Work Description: gemmellr commented on PR #4447: URL: https://github.com/apache/activemq-artemis/pull/4447#issuecomment-1533154934 Seems good to me, would be good to get a review from folks more familiar with the core client. Issue Time Tracking --- Worklog Id: (was: 860362) Time Spent: 1h 50m (was: 1h 40m) > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4266) Mitigate NPE with bad SSL config
[
https://issues.apache.org/jira/browse/ARTEMIS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4266.
-
Fix Version/s: 2.29.0
Resolution: Fixed
> Mitigate NPE with bad SSL config
>
>
> Key: ARTEMIS-4266
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4266
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an {{acceptor}} is configured with {{sslEnabled=true}} and nothing else
> the broker will thrown an NPE instead of the proper exception with the proper
> explanation of the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4267) Original exception lost for NoCacheLoginException
[ https://issues.apache.org/jira/browse/ARTEMIS-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4267. - Fix Version/s: 2.29.0 Resolution: Fixed > Original exception lost for NoCacheLoginException > - > > Key: ARTEMIS-4267 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4267 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When skipping the authentication cache the _original_ exception is not logged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4208) OpenWire ChunkSend issuing CriticalAnalyzer
[ https://issues.apache.org/jira/browse/ARTEMIS-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4208. Resolution: Fixed > OpenWire ChunkSend issuing CriticalAnalyzer > --- > > Key: ARTEMIS-4208 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4208 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Openwire large message send can eventually slow down and issue a > CriticalAnalyzer. > "Thread-15 > (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@25dd)" > Id=85 TIMED_WAITING on io.netty.channel.DefaultChannelPromise@2d6cc1dc > at java.base@11.0.18/java.lang.Object.wait(Native Method) > - waiting on io.netty.channel.DefaultChannelPromise@2d6cc1dc > at java.base@11.0.18/java.lang.Object.wait(Object.java:462) > at io.netty.util.concurrent.DefaultPromise.await0(DefaultPromise.java:679) > at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:299) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.waitFor(NettyConnection.java:94) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.flushAndWait(NettyConnection.java:381) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:375) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:292) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.chunkSend(OpenWireConnection.java:588) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.physicalSend(OpenWireConnection.java:561) > - locked > org.apache.activemq.artemis.core.remoting.impl.netty.NettyServerConnection@45fefd05 > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.sendCommand(OpenWireConnection.java:890) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.deliverMessage(OpenWireConnection.java:686) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.deliverMessage(AMQSession.java:558) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQConsumer.handleDeliver(AMQConsumer.java:295) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.sendMessage(AMQSession.java:315) > at > org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1170) > at > org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:510) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:3886) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:3179) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4260) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$224/0x00084033f040.run(Unknown > Source) > at > java.base@11.0.18/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base@11.0.18/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4208) OpenWire ChunkSend issuing CriticalAnalyzer
[ https://issues.apache.org/jira/browse/ARTEMIS-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reassigned ARTEMIS-4208: Assignee: Clebert Suconic > OpenWire ChunkSend issuing CriticalAnalyzer > --- > > Key: ARTEMIS-4208 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4208 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Openwire large message send can eventually slow down and issue a > CriticalAnalyzer. > "Thread-15 > (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@25dd)" > Id=85 TIMED_WAITING on io.netty.channel.DefaultChannelPromise@2d6cc1dc > at java.base@11.0.18/java.lang.Object.wait(Native Method) > - waiting on io.netty.channel.DefaultChannelPromise@2d6cc1dc > at java.base@11.0.18/java.lang.Object.wait(Object.java:462) > at io.netty.util.concurrent.DefaultPromise.await0(DefaultPromise.java:679) > at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:299) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.waitFor(NettyConnection.java:94) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.flushAndWait(NettyConnection.java:381) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:375) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnection.write(NettyConnection.java:292) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.chunkSend(OpenWireConnection.java:588) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.physicalSend(OpenWireConnection.java:561) > - locked > org.apache.activemq.artemis.core.remoting.impl.netty.NettyServerConnection@45fefd05 > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.sendCommand(OpenWireConnection.java:890) > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.deliverMessage(OpenWireConnection.java:686) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.deliverMessage(AMQSession.java:558) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQConsumer.handleDeliver(AMQConsumer.java:295) > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.sendMessage(AMQSession.java:315) > at > org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1170) > at > org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:510) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:3886) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:3179) > at > org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:4260) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:56) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:67) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$224/0x00084033f040.run(Unknown > Source) > at > java.base@11.0.18/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base@11.0.18/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[
https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=860327=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860327
]
ASF GitHub Bot logged work on ARTEMIS-4251:
---
Author: ASF GitHub Bot
Created on: 03/May/23 12:56
Start Date: 03/May/23 12:56
Worklog Time Spent: 10m
Work Description: brusdev commented on code in PR #4447:
URL: https://github.com/apache/activemq-artemis/pull/4447#discussion_r1183650110
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java:
##
@@ -664,33 +669,94 @@ private void failoverOrReconnect(final Object
connectionID,
sessionsToFailover = new HashSet<>(sessions);
}
+ // Notify sessions before failover.
for (ClientSessionInternal session : sessionsToFailover) {
session.preHandleFailover(connection);
}
- boolean allSessionReconnected = false;
- int failedReconnectSessionsCounter = 0;
- do {
- allSessionReconnected =
reconnectSessions(sessionsToFailover, oldConnection, reconnectAttempts, me);
- if (oldConnection != null) {
- oldConnection.destroy();
+
+ // Try to reconnect to the current connector pair.
+ // Before ARTEMIS-4251 ClientSessionFactoryImpl only tries to
reconnect to the current connector pair.
+ int reconnectRetries = 0;
+ boolean sessionsReconnected = false;
+ BiPredicate reconnectRetryPredicate =
+ (reconnected, retries) -> clientProtocolManager.isAlive() &&
+ !reconnected && (reconnectAttempts == -1 || retries <
reconnectAttempts);
+ while (reconnectRetryPredicate.test(sessionsReconnected,
reconnectRetries)) {
+
+ int remainingReconnectRetries = reconnectAttempts == -1 ? -1
: reconnectAttempts - reconnectRetries;
+ reconnectRetries +=
getConnectionWithRetry(remainingReconnectRetries, oldConnection);
+
+ if (connection != null) {
+ sessionsReconnected =
reconnectSessions(sessionsToFailover, oldConnection, me);
+
+ if (!sessionsReconnected) {
+if (oldConnection != null) {
+ oldConnection.destroy();
+}
+
+oldConnection = connection;
+connection = null;
+ }
+ }
+
+ reconnectRetries++;
+ if (reconnectRetryPredicate.test(sessionsReconnected,
reconnectRetries)) {
+ waitForRetry(retryInterval);
}
+ }
- if (!allSessionReconnected) {
- failedReconnectSessionsCounter++;
- oldConnection = connection;
- connection = null;
- // Wait for retry when the connection is established but
not all session are reconnected.
- if ((reconnectAttempts == -1 ||
failedReconnectSessionsCounter < reconnectAttempts) && oldConnection != null) {
+ // Try to connect to other connector pairs.
+ // After ARTEMIS-4251 ClientSessionFactoryImpl tries to connect
to
+ // other connector pairs when reconnection o the current
connector pair fails.
+ int failoverReties = 0;
+ int connectorsCount = 0;
+ Pair
connectorPair;
+ BiPredicate failoverRetryPredicate =
+ (reconnected, retries) -> clientProtocolManager.isAlive() &&
+ !reconnected && (failoverAttempts == -1 || retries <
failoverAttempts);
+ while (failoverRetryPredicate.test(sessionsReconnected,
failoverReties)) {
+
+ connectorsCount++;
+ connectorPair = serverLocator.selectNextConnectorPair();
+
+ if (connectorPair != null) {
+ connectorConfig = connectorPair.getA();
+ currentConnectorConfig = connectorPair.getA();
+ if (connectorPair.getB() != null) {
+backupConnectorConfig = connectorPair.getB();
+ }
+
+ getConnection();
+ }
+
+ if (connection != null) {
+ sessionsReconnected =
reconnectSessions(sessionsToFailover, oldConnection, me);
+
+ if (!sessionsReconnected) {
+if (oldConnection != null) {
+ oldConnection.destroy();
+}
+
+oldConnection = connection;
+
[jira] [Resolved] (ARTEMIS-4201) Not sending proper MQTT disconnect code on stolen link
[ https://issues.apache.org/jira/browse/ARTEMIS-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-4201. - Fix Version/s: 2.29.0 Resolution: Fixed > Not sending proper MQTT disconnect code on stolen link > -- > > Key: ARTEMIS-4201 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4201 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > > When an MQTT 3.1.1 client steals the link from an MQTT 5 client (by > connecting with the same client ID) the broker is not sending the proper > disconnect code to the MQTT 5 client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?focusedWorklogId=860325=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860325 ] ASF GitHub Bot logged work on ARTEMIS-4244: --- Author: ASF GitHub Bot Created on: 03/May/23 12:35 Start Date: 03/May/23 12:35 Worklog Time Spent: 10m Work Description: gemmellr commented on PR #4465: URL: https://github.com/apache/activemq-artemis/pull/4465#issuecomment-1532955514 Fixup for #4441 where I missed that during the updates, oopsie :) Issue Time Tracking --- Worklog Id: (was: 860325) Time Spent: 1h 40m (was: 1.5h) > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4251) Support CORE client failover to other live servers
[
https://issues.apache.org/jira/browse/ARTEMIS-4251?focusedWorklogId=860321=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860321
]
ASF GitHub Bot logged work on ARTEMIS-4251:
---
Author: ASF GitHub Bot
Created on: 03/May/23 12:30
Start Date: 03/May/23 12:30
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4447:
URL: https://github.com/apache/activemq-artemis/pull/4447#discussion_r1182744430
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java:
##
@@ -664,33 +669,94 @@ private void failoverOrReconnect(final Object
connectionID,
sessionsToFailover = new HashSet<>(sessions);
}
+ // Notify sessions before failover.
for (ClientSessionInternal session : sessionsToFailover) {
session.preHandleFailover(connection);
}
- boolean allSessionReconnected = false;
- int failedReconnectSessionsCounter = 0;
- do {
- allSessionReconnected =
reconnectSessions(sessionsToFailover, oldConnection, reconnectAttempts, me);
- if (oldConnection != null) {
- oldConnection.destroy();
+
+ // Try to reconnect to the current connector pair.
+ // Before ARTEMIS-4251 ClientSessionFactoryImpl only tries to
reconnect to the current connector pair.
+ int reconnectRetries = 0;
+ boolean sessionsReconnected = false;
+ BiPredicate reconnectRetryPredicate =
+ (reconnected, retries) -> clientProtocolManager.isAlive() &&
+ !reconnected && (reconnectAttempts == -1 || retries <
reconnectAttempts);
+ while (reconnectRetryPredicate.test(sessionsReconnected,
reconnectRetries)) {
+
+ int remainingReconnectRetries = reconnectAttempts == -1 ? -1
: reconnectAttempts - reconnectRetries;
+ reconnectRetries +=
getConnectionWithRetry(remainingReconnectRetries, oldConnection);
+
+ if (connection != null) {
+ sessionsReconnected =
reconnectSessions(sessionsToFailover, oldConnection, me);
+
+ if (!sessionsReconnected) {
+if (oldConnection != null) {
+ oldConnection.destroy();
+}
+
+oldConnection = connection;
+connection = null;
+ }
+ }
+
+ reconnectRetries++;
+ if (reconnectRetryPredicate.test(sessionsReconnected,
reconnectRetries)) {
+ waitForRetry(retryInterval);
}
+ }
- if (!allSessionReconnected) {
- failedReconnectSessionsCounter++;
- oldConnection = connection;
- connection = null;
- // Wait for retry when the connection is established but
not all session are reconnected.
- if ((reconnectAttempts == -1 ||
failedReconnectSessionsCounter < reconnectAttempts) && oldConnection != null) {
+ // Try to connect to other connector pairs.
+ // After ARTEMIS-4251 ClientSessionFactoryImpl tries to connect
to
+ // other connector pairs when reconnection o the current
connector pair fails.
+ int failoverReties = 0;
Review Comment:
Reties = Retries
##
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java:
##
@@ -664,33 +669,94 @@ private void failoverOrReconnect(final Object
connectionID,
sessionsToFailover = new HashSet<>(sessions);
}
+ // Notify sessions before failover.
for (ClientSessionInternal session : sessionsToFailover) {
session.preHandleFailover(connection);
}
- boolean allSessionReconnected = false;
- int failedReconnectSessionsCounter = 0;
- do {
- allSessionReconnected =
reconnectSessions(sessionsToFailover, oldConnection, reconnectAttempts, me);
- if (oldConnection != null) {
- oldConnection.destroy();
+
+ // Try to reconnect to the current connector pair.
+ // Before ARTEMIS-4251 ClientSessionFactoryImpl only tries to
reconnect to the current connector pair.
+ int reconnectRetries = 0;
+ boolean sessionsReconnected = false;
+ BiPredicate reconnectRetryPredicate =
+ (reconnected, retries) -> clientProtocolManager.isAlive() &&
+
[jira] [Work logged] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?focusedWorklogId=860295=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860295 ] ASF GitHub Bot logged work on ARTEMIS-4244: --- Author: ASF GitHub Bot Created on: 03/May/23 11:27 Start Date: 03/May/23 11:27 Worklog Time Spent: 10m Work Description: brusdev merged PR #4465: URL: https://github.com/apache/activemq-artemis/pull/4465 Issue Time Tracking --- Worklog Id: (was: 860295) Time Spent: 1.5h (was: 1h 20m) > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718899#comment-17718899 ] ASF subversion and git services commented on ARTEMIS-4244: -- Commit fb1fa6a95f3e49b21a13d66a706a49d3e3fee61b in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fb1fa6a95f ] ARTEMIS-4244 Fix testSetWebBindingProperties > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[
https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=860276=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860276
]
ASF GitHub Bot logged work on ARTEMIS-4238:
---
Author: ASF GitHub Bot
Created on: 03/May/23 10:38
Start Date: 03/May/23 10:38
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4435:
URL: https://github.com/apache/activemq-artemis/pull/4435#discussion_r1183518415
##
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationSpec.java:
##
@@ -631,6 +632,7 @@ public Integer getTransactionTimeout() {
*
* @param value The value
*/
+ @Deprecated
Review Comment:
Ditto
Issue Time Tracking
---
Worklog Id: (was: 860276)
Time Spent: 1.5h (was: 1h 20m)
> transaction timeout ActivationConfigProperty is no longer working
> -
>
> Key: ARTEMIS-4238
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4238
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.28.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> ARTEMIS-3707 has created a regression where the transactionTimeout
> ActivationConfigProperty is no longer working properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?focusedWorklogId=860275=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860275 ] ASF GitHub Bot logged work on ARTEMIS-4238: --- Author: ASF GitHub Bot Created on: 03/May/23 10:37 Start Date: 03/May/23 10:37 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #4435: URL: https://github.com/apache/activemq-artemis/pull/4435#discussion_r1183517862 ## artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationSpec.java: ## @@ -120,6 +120,7 @@ public class ActiveMQActivationSpec extends ConnectionFactoryProperties implemen /** * Transaction timeout */ + @Deprecated Review Comment: If it is deprecated for future removal as indicated in the documentation, should the Deprecated tag indicate that with the forRemoval flag? Issue Time Tracking --- Worklog Id: (was: 860275) Time Spent: 1h 20m (was: 1h 10m) > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9254:
Issue Type: Bug (was: Task)
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9254:
Component/s: KahaDB
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-9254.
-
Resolution: Fixed
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718876#comment-17718876
]
ASF subversion and git services commented on AMQ-9254:
--
Commit 6a64a0817e93991515eb89ee09ddc468452bd1c3 in activemq's branch
refs/heads/activemq-5.17.x from Christopher L. Shannon (cshannon)
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=6a64a0817e ]
AMQ-9254 - Rework data file size validation and add unit test
This isolates the validation on data file length on read and adds unit
tests to verify we properly fallback to the real file length on initial
size check failure
(cherry picked from commit bcc74f93fe6dbbd5c795c35484db8efa29b254b6)
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718875#comment-17718875
]
ASF subversion and git services commented on AMQ-9254:
--
Commit 78a399cb8714c6b7cd0bbcaa6be21fa217399033 in activemq's branch
refs/heads/activemq-5.18.x from Christopher L. Shannon (cshannon)
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=78a399cb87 ]
AMQ-9254 - Rework data file size validation and add unit test
This isolates the validation on data file length on read and adds unit
tests to verify we properly fallback to the real file length on initial
size check failure
(cherry picked from commit bcc74f93fe6dbbd5c795c35484db8efa29b254b6)
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718873#comment-17718873
]
ASF subversion and git services commented on AMQ-9254:
--
Commit b8b5dedb781677970c227d1cc972397cb994b901 in activemq's branch
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=b8b5dedb78 ]
Merge pull request #1004 from mattrpav/AMQ-9254
[AMQ-9254] DataFile readRecord fallback to OS file.length in rare edge case
Rework validation that the record read won't exceed the length of the file
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17718872#comment-17718872
]
ASF subversion and git services commented on AMQ-9254:
--
Commit bcc74f93fe6dbbd5c795c35484db8efa29b254b6 in activemq's branch
refs/heads/main from Christopher L. Shannon (cshannon)
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=bcc74f93fe ]
AMQ-9254 - Rework data file size validation and add unit test
This isolates the validation on data file length on read and adds unit
tests to verify we properly fallback to the real file length on initial
size check failure
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9254) KahaDB minor fix when db files may be larger than max length
[
https://issues.apache.org/jira/browse/AMQ-9254?focusedWorklogId=860259=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860259
]
ASF GitHub Bot logged work on AMQ-9254:
---
Author: ASF GitHub Bot
Created on: 03/May/23 10:04
Start Date: 03/May/23 10:04
Worklog Time Spent: 10m
Work Description: cshannon merged PR #1004:
URL: https://github.com/apache/activemq/pull/1004
Issue Time Tracking
---
Worklog Id: (was: 860259)
Time Spent: 0.5h (was: 20m)
> KahaDB minor fix when db files may be larger than max length
>
>
> Key: AMQ-9254
> URL: https://issues.apache.org/jira/browse/AMQ-9254
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Minor
> Fix For: 5.19.0, 5.17.5, 5.18.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Log message:
> {noformat}
> Caused by: java.io.IOException: Invalid location size: 54:33554460, size: 2412
> at
> org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord(DataFileAccessor.java:88)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.disk.journal.Journal.read(Journal.java:953)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:1197)
> ~[?:?]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:1401)
> ~[?:?]
> ... 74 more
> {noformat}
> db-54.log size: 33556877
> Note: This read would have succeeded otherwise.
> Reproducible test case:
> ref: https://github.com/mattrpav/activemq-jira-9254
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
[
https://issues.apache.org/jira/browse/ARTEMIS-4212?focusedWorklogId=860249=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-860249
]
ASF GitHub Bot logged work on ARTEMIS-4212:
---
Author: ASF GitHub Bot
Created on: 03/May/23 09:17
Start Date: 03/May/23 09:17
Worklog Time Spent: 10m
Work Description: brusdev commented on PR #4464:
URL:
https://github.com/apache/activemq-artemis/pull/4464#issuecomment-1532699841
The test
`org.apache.activemq.artemis.tests.integration.jms.RedeployTest.testRedeployDivertsWithManagementChange`
fails:
```
java.lang.IllegalArgumentException: AMQ229247: Invalid address configuration
for 'a'. Address must support multicast and/or anycast.
at
org.apache.activemq.artemis.tests.integration.jms.RedeployTest.testRedeployDivertsWithManagementChange(RedeployTest.java:367)
```
Issue Time Tracking
---
Worklog Id: (was: 860249)
Time Spent: 6h 10m (was: 6h)
> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---
>
> Key: ARTEMIS-4212
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the
> routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a
> different routing type, the expected behavior would be to throw some sort of
> InvalidDestinationException (if auto-create is not enabled), or to create the
> matching address and queue with the appropriate routing type. The routing
> count on the existing address (with non-matching routing type) should remain
> unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a
> multiccast (Topic) producer, the routed count on the address is incremented,
> but the message count on the matching queue is not. No indication is given at
> the client end that the messages failed to get routed - they are silently
> dropped.
> This is reproducible using a qpid / proton queue producer to send to a
> multicast address or using a topic producer to send to an anycast address,
> e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to
> "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST
> routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched
> routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin
> --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the
> address level, but remains unchanged at the destination level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
