[jira] [Commented] (ARTEMIS-4538) Update mirroring documentation to clarify format of mirroring connection URIs
[
https://issues.apache.org/jira/browse/ARTEMIS-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797259#comment-17797259
]
Robbie Gemmell commented on ARTEMIS-4538:
-
The reference may not have existed at that time. I dont think it really makes
sense to add something to the mirroring section specifically, when its already
covered by the initial general section covering configuring a broker-connection
at all, including the URL. Would we than also add it to the 4 other connection
sub-element types, given the mirroring one is no different than the other 4 in
this regard? I dont see that making sense. This is already just pointing out it
is configured the same way this stuff is everywhere else in the broker, when
nothing has been said to suggest otherwise. Once seems enough.
> Update mirroring documentation to clarify format of mirroring connection URIs
> -
>
> Key: ARTEMIS-4538
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4538
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: John Clifford
>Priority: Major
>
> The [Artemis
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html]
> explains how to make a connection for mirroring using the
> {{}} configuration. However, it isn't clear what format the
> connection URI takes. In particularly, it isn't clear how to configure it to
> use TLS.
> I understand that the URI format is, in fact, the same as that used by other
> Artemis network connections. I would not have guessed this, because Artemis
> does not use AMQP for any of these other connections, and I just assumed that
> AMQP mirroring connections would be configured differently.
> So I think all that is needed here is one additional line explaining this,
> and perhaps linking to the relevant section of the docs. A specific example
> of configuring a mirror connection using TLS would, I think, provide useful
> additional help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (ARTEMIS-4539) simplify various release process steps
[ https://issues.apache.org/jira/browse/ARTEMIS-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-4539 started by Robbie Gemmell. --- > simplify various release process steps > -- > > Key: ARTEMIS-4539 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4539 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > There are currently a lot of manual steps during the release process that > involve running various commands from the RELEASING.md document, with various > c generally involved. They aren't difficult steps, but it does make the > process more cumbersome, fragile, and significantly slower than it need > actually be. We can script various aspects of the updates so just some simple > easily-remembered/discovered commands can be run to do most of the work, > simplifying the release process and making it much less of a chore to > actually do releases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4539) simplify various release process steps
Robbie Gemmell created ARTEMIS-4539: --- Summary: simplify various release process steps Key: ARTEMIS-4539 URL: https://issues.apache.org/jira/browse/ARTEMIS-4539 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 There are currently a lot of manual steps during the release process that involve running various commands from the RELEASING.md document, with various c generally involved. They aren't difficult steps, but it does make the process more cumbersome, fragile, and significantly slower than it need actually be. We can script various aspects of the updates so just some simple easily-remembered/discovered commands can be run to do most of the work, simplifying the release process and making it much less of a chore to actually do releases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4538) Update mirroring documentation to clarify format of mirroring connection URIs
[
https://issues.apache.org/jira/browse/ARTEMIS-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797239#comment-17797239
]
Robbie Gemmell edited comment on ARTEMIS-4538 at 12/15/23 4:21 PM:
---
The documentation has a specific note already that the TLS config for broker
connections is in fact not configured differently than any other broker TLS
connection config, just in case anyone should assume they were for $reasons I
dont understand. There is also already a specific example referenced showing
how to configure TLS for an amqp broker connection:
[https://github.com/apache/activemq-artemis-examples/tree/main/examples/features/broker-connection/amqp-sending-overssl.]
[https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html#amqp-server-connections]
"Note that the connection URI options for transport settings such as enabling
and configuring TLS are common with other Artemis connector URIs. See [the
transport
doc|https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-ssl]
for more. An example configuration for a TLS AMQP broker-connection can be
found in the broker examples at
./examples/features/broker-connection/amqp-sending-overssl."
(The example reference could be updated for 2.32.0 to point to the new examples
repo, I'll take of that under ARTEMIS-4533)
was (Author: gemmellr):
The documentation has a specific note already that the TLS config for broker
connections is in fact not configured differently than any other broker TLS
connection config, just in case anyone should assume they were for $reasons I
dont understand. There is also already a specific example showing how to
configure TLS for an amqp broker connection:
[https://github.com/apache/activemq-artemis-examples/tree/main/examples/features/broker-connection/amqp-sending-overssl.]
https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html#amqp-server-connections
"Note that the connection URI options for transport settings such as enabling
and configuring TLS are common with other Artemis connector URIs. See [the
transport
doc|https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-ssl]
for more. An example configuration for a TLS AMQP broker-connection can be
found in the broker examples at
./examples/features/broker-connection/amqp-sending-overssl.
(The example reference could be updated for 2.32.0 to point to the new examples
repo, I'll take of that under ARTEMIS-4533)
> Update mirroring documentation to clarify format of mirroring connection URIs
> -
>
> Key: ARTEMIS-4538
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4538
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: John Clifford
>Priority: Major
>
> The [Artemis
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html]
> explains how to make a connection for mirroring using the
> {{}} configuration. However, it isn't clear what format the
> connection URI takes. In particularly, it isn't clear how to configure it to
> use TLS.
> I understand that the URI format is, in fact, the same as that used by other
> Artemis network connections. I would not have guessed this, because Artemis
> does not use AMQP for any of these other connections, and I just assumed that
> AMQP mirroring connections would be configured differently.
> So I think all that is needed here is one additional line explaining this,
> and perhaps linking to the relevant section of the docs. A specific example
> of configuring a mirror connection using TLS would, I think, provide useful
> additional help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4538) Update mirroring documentation to clarify format of mirroring connection URIs
[
https://issues.apache.org/jira/browse/ARTEMIS-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797239#comment-17797239
]
Robbie Gemmell commented on ARTEMIS-4538:
-
The documentation has a specific note already that the TLS config for broker
connections is in fact not configured differently than any other broker TLS
connection config, just in case anyone should assume they were for $reasons I
dont understand. There is also already a specific example showing how to
configure TLS for an amqp broker connection:
[https://github.com/apache/activemq-artemis-examples/tree/main/examples/features/broker-connection/amqp-sending-overssl.]
https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html#amqp-server-connections
"Note that the connection URI options for transport settings such as enabling
and configuring TLS are common with other Artemis connector URIs. See [the
transport
doc|https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-ssl]
for more. An example configuration for a TLS AMQP broker-connection can be
found in the broker examples at
./examples/features/broker-connection/amqp-sending-overssl.
(The example reference could be updated for 2.32.0 to point to the new examples
repo, I'll take of that under ARTEMIS-4533)
> Update mirroring documentation to clarify format of mirroring connection URIs
> -
>
> Key: ARTEMIS-4538
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4538
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: John Clifford
>Priority: Major
>
> The [Artemis
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html]
> explains how to make a connection for mirroring using the
> {{}} configuration. However, it isn't clear what format the
> connection URI takes. In particularly, it isn't clear how to configure it to
> use TLS.
> I understand that the URI format is, in fact, the same as that used by other
> Artemis network connections. I would not have guessed this, because Artemis
> does not use AMQP for any of these other connections, and I just assumed that
> AMQP mirroring connections would be configured differently.
> So I think all that is needed here is one additional line explaining this,
> and perhaps linking to the relevant section of the docs. A specific example
> of configuring a mirror connection using TLS would, I think, provide useful
> additional help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4533) Move the examples to their own repository
[ https://issues.apache.org/jira/browse/ARTEMIS-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4533. - Resolution: Fixed > Move the examples to their own repository > - > > Key: ARTEMIS-4533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4533 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As previously discussed > ([here|https://lists.apache.org/thread/jq783v0ywpgsnty6fw0n2nmxogjh935p]) the > examples will be moved to their own independent repository rather than being > part of the main Artemis repository and build. > The new examples repository will be: > [https://github.com/apache/activemq-artemis-examples/] > The examples repo _main_ branch will target the current Artemis release, with > changes toward/requiring the next release occurring on the _development_ > branch prior to the Artemis release happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4534) Move the examples to their own repository
[ https://issues.apache.org/jira/browse/ARTEMIS-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4534. --- Resolution: Duplicate > Move the examples to their own repository > - > > Key: ARTEMIS-4534 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4534 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > As previously discussed > ([here|https://lists.apache.org/thread/jq783v0ywpgsnty6fw0n2nmxogjh935p]) the > examples will be moved to their own independent repository rather than being > part of the main Artemis repository and build. > The new examples repository will be: > [https://github.com/apache/activemq-artemis-examples/] > The examples repo _main_ branch will target the current Artemis release, with > changes toward/requiring the next release occurring on the _development_ > branch prior to the Artemis release happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (ARTEMIS-4534) Move the examples to their own repository
[ https://issues.apache.org/jira/browse/ARTEMIS-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell deleted ARTEMIS-4534: > Move the examples to their own repository > - > > Key: ARTEMIS-4534 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4534 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > > As previously discussed > ([here|https://lists.apache.org/thread/jq783v0ywpgsnty6fw0n2nmxogjh935p]) the > examples will be moved to their own independent repository rather than being > part of the main Artemis repository and build. > The new examples repository will be: > [https://github.com/apache/activemq-artemis-examples/] > The examples repo _main_ branch will target the current Artemis release, with > changes toward/requiring the next release occurring on the _development_ > branch prior to the Artemis release happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4534) Move the examples to their own repository
Robbie Gemmell created ARTEMIS-4534: --- Summary: Move the examples to their own repository Key: ARTEMIS-4534 URL: https://issues.apache.org/jira/browse/ARTEMIS-4534 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 As previously discussed ([here|https://lists.apache.org/thread/jq783v0ywpgsnty6fw0n2nmxogjh935p]) the examples will be moved to their own independent repository rather than being part of the main Artemis repository and build. The new examples repository will be: [https://github.com/apache/activemq-artemis-examples/] The examples repo _main_ branch will target the current Artemis release, with changes toward/requiring the next release occurring on the _development_ branch prior to the Artemis release happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4533) Move the examples to their own repository
Robbie Gemmell created ARTEMIS-4533: --- Summary: Move the examples to their own repository Key: ARTEMIS-4533 URL: https://issues.apache.org/jira/browse/ARTEMIS-4533 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 As previously discussed ([here|https://lists.apache.org/thread/jq783v0ywpgsnty6fw0n2nmxogjh935p]) the examples will be moved to their own independent repository rather than being part of the main Artemis repository and build. The new examples repository will be: [https://github.com/apache/activemq-artemis-examples/] The examples repo _main_ branch will target the current Artemis release, with changes toward/requiring the next release occurring on the _development_ branch prior to the Artemis release happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9413) WebSite / AMQ6 confusion
[
https://issues.apache.org/jira/browse/AMQ-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795415#comment-17795415
]
Robbie Gemmell commented on AMQ-9413:
-
Please ask questions on the users list or chat
https://activemq.apache.org/contact
ActiveMQ 6.0.0 is essentially a Jakarta'fied continuation of the ActiveMQ
5.18.x codebase, with related updates like switching to using Spring 6,
necessarily requiring Java 17 minimum, and other changes appropriate to the new
release stream. For a long time it was just going to be called 5.19.x but
following more recent discussion 6.x was used as it seemed clearer and more
appropriate especially as javax and jakarta release streams are likely to
coexist for some time. Artemis is still being developed and nothing really
changed there as Artemis releases have included both JMS 2 and Jakarta
Messaging 3.x support since 2021.
> WebSite / AMQ6 confusion
>
>
> Key: AMQ-9413
> URL: https://issues.apache.org/jira/browse/AMQ-9413
> Project: ActiveMQ
> Issue Type: Bug
> Components: website
>Affects Versions: 6.0.0, 6.0.1
>Reporter: Mike Lothian
>Priority: Minor
>
> Is ActiveMQ 6 now the previous ArtemisMQ code?
> If so does that mean Artemis is no longer being developed? Or is it just the
> next set of feature work
> activemq.apache.org doesn't really make this clear and I think is still using
> the wording from pre-6
> This section in particular:
> {quote}There are currently two "flavors" of ActiveMQ available - the
> well-known "classic" broker and the "next generation" broker code-named
> {_}Artemis{_}. Once Artemis reaches a sufficient level of feature parity with
> the "Classic" code-base it will become the next major version of ActiveMQ.
> Initial [migration
> documentation|https://activemq.apache.org/components/artemis/migration] is
> available as well as a development
> [roadmap|https://activemq.apache.org/activemq-artemis-roadmap] for Artemis.
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AMQ-9413) WebSite / AMQ6 confusion
[
https://issues.apache.org/jira/browse/AMQ-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved AMQ-9413.
-
Resolution: Information Provided
> WebSite / AMQ6 confusion
>
>
> Key: AMQ-9413
> URL: https://issues.apache.org/jira/browse/AMQ-9413
> Project: ActiveMQ
> Issue Type: Bug
> Components: website
>Affects Versions: 6.0.0, 6.0.1
>Reporter: Mike Lothian
>Priority: Minor
>
> Is ActiveMQ 6 now the previous ArtemisMQ code?
> If so does that mean Artemis is no longer being developed? Or is it just the
> next set of feature work
> activemq.apache.org doesn't really make this clear and I think is still using
> the wording from pre-6
> This section in particular:
> {quote}There are currently two "flavors" of ActiveMQ available - the
> well-known "classic" broker and the "next generation" broker code-named
> {_}Artemis{_}. Once Artemis reaches a sufficient level of feature parity with
> the "Classic" code-base it will become the next major version of ActiveMQ.
> Initial [migration
> documentation|https://activemq.apache.org/components/artemis/migration] is
> available as well as a development
> [roadmap|https://activemq.apache.org/activemq-artemis-roadmap] for Artemis.
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4511) prevent MainTest failure causing knock-on failures in later tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4511. - Resolution: Fixed > prevent MainTest failure causing knock-on failures in later tests > - > > Key: ARTEMIS-4511 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4511 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Affects Versions: 2.31.2 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > There is a 'MainTest' class testing behaviour of a main method to be used in > simple images. If it fails, e.g the timing out, it can leave resources in > place that cause subsequent ActiveMQTestBase tests to fail. Add some cleanup > to prevent this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4511) prevent MainTest failure causing knock-on failures in later tests
Robbie Gemmell created ARTEMIS-4511: --- Summary: prevent MainTest failure causing knock-on failures in later tests Key: ARTEMIS-4511 URL: https://issues.apache.org/jira/browse/ARTEMIS-4511 Project: ActiveMQ Artemis Issue Type: Task Components: Tests Affects Versions: 2.31.2 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 There is a 'MainTest' class testing behaviour of a main method to be used in simple images. If it fails, e.g the timing out, it can leave resources in place that cause subsequent ActiveMQTestBase tests to fail. Add some cleanup to prevent this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4502) Allow core messages to cross AMQP broker connection links without conversion
[ https://issues.apache.org/jira/browse/ARTEMIS-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4502. - Resolution: Fixed > Allow core messages to cross AMQP broker connection links without conversion > > > Key: ARTEMIS-4502 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4502 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: AMQP >Affects Versions: 2.31.2 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently when message cross AMQP broker connection links used for mirroring > or federation they must be converted from Core to AMQP and then eventually > back if sent to a core consumer. This is worse for large messages as they > must be fully loaded into memory before converting to AMQP. > For AMQP Federation and broker mirroring we should use special encoding and > decoding to convey the core and core large messages across the wire without > conversion to avoid the overhead and caveats of that conversion. This > requires some not insignificant refactoring and use of custom message format > values to signal when an AMQP delivery is a core message so that the protocol > head can recreate the core message from the sent data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4509) ActiveMQTestBase leak check should identify state clearly without need of logs
[ https://issues.apache.org/jira/browse/ARTEMIS-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4509. - Resolution: Fixed > ActiveMQTestBase leak check should identify state clearly without need of logs > -- > > Key: ARTEMIS-4509 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4509 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.31.2 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > The ActiveMQTestBase class does some leak checking on the LibaioContext > resource usage during the test suite. There is a pre-class check that logs > when it first detects a leak happened before the (typically in a > non-ActiveMQTestBase test class), or fails immediately if a previous class > has detected the leak and failed (after), and a post-class check that fails > if things dont hit 0-usage within 30 seconds. > This is fine for local usage but is a bit of a pain for cases where the > pre-class foul happens in a CI env, as it isnt always so easy to find, get, > and examine the full specific class logs to determine the precise status of > when the issue occurred. It would be more useful if the pre-class foul > detection actually just failed immediately (as will already happen after) and > created an error that explicitly identifies the status from the test fail > without needing to examine the logs at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4509) ActiveMQTestBase leak check should identify state clearly without need of logs
Robbie Gemmell created ARTEMIS-4509: --- Summary: ActiveMQTestBase leak check should identify state clearly without need of logs Key: ARTEMIS-4509 URL: https://issues.apache.org/jira/browse/ARTEMIS-4509 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.31.2 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 The ActiveMQTestBase class does some leak checking on the LibaioContext resource usage during the test suite. There is a pre-class check that logs when it first detects a leak happened before the (typically in a non-ActiveMQTestBase test class), or fails immediately if a previous class has detected the leak and failed (after), and a post-class check that fails if things dont hit 0-usage within 30 seconds. This is fine for local usage but is a bit of a pain for cases where the pre-class foul happens in a CI env, as it isnt always so easy to find, get, and examine the full specific class logs to determine the precise status of when the issue occurred. It would be more useful if the pre-class foul detection actually just failed immediately (as will already happen after) and created an error that explicitly identifies the status from the test fail without needing to examine the logs at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4504) running examples creates unexpected dirs/files (or shows failure trying)
[
https://issues.apache.org/jira/browse/ARTEMIS-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4504.
-
Resolution: Fixed
> running examples creates unexpected dirs/files (or shows failure trying)
>
>
> Key: ARTEMIS-4504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4504
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 2.32.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running one of the examples with e.g mvn verify will typically create and
> leave behind an unexpected sub directory within the example source dir called
> "${sys:artemis.instance}/log" with [empty] artemis.log and audit.log files
> inside. Alternatively, on some systems it may instead fail while trying to do
> this and display an error message about it.
> This happens because the plugin used by the examples first creates a broker
> instance within the target directory, prompting creation of a related
> log4j2.properties file, then at the end of the example the plugin is again
> used to run the CLI stop command to shut down the broker, the process for
> which currently runs the CLI class directly without some of the configuration
> properties the CLI script normally sets, and in doing this puts the broker
> instance log42.properties file on the classpath and then causes log4j to be
> initialised which leads to the erroneous dir+file creation due to the missing
> props. We can resolve this by updating the example/plugin to call the CLI
> script such that the needed config is actually present.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (ARTEMIS-4504) running examples creates unexpected dirs/files (or shows failure trying)
[
https://issues.apache.org/jira/browse/ARTEMIS-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on ARTEMIS-4504 started by Robbie Gemmell.
---
> running examples creates unexpected dirs/files (or shows failure trying)
>
>
> Key: ARTEMIS-4504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4504
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 2.32.0
>
>
> Running one of the examples with e.g mvn verify will typically create and
> leave behind an unexpected sub directory within the example source dir called
> "${sys:artemis.instance}/log" with [empty] artemis.log and audit.log files
> inside. Alternatively, on some systems it may instead fail while trying to do
> this and display an error message about it.
> This happens because the plugin used by the examples first creates a broker
> instance within the target directory, prompting creation of a related
> log4j2.properties file, then at the end of the example the plugin is again
> used to run the CLI stop command to shut down the broker, the process for
> which currently runs the CLI class directly without some of the configuration
> properties the CLI script normally sets, and in doing this puts the broker
> instance log42.properties file on the classpath and then causes log4j to be
> initialised which leads to the erroneous dir+file creation due to the missing
> props. We can resolve this by updating the example/plugin to call the CLI
> script such that the needed config is actually present.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4504) running examples creates unexpected dirs/files (or shows failure trying)
Robbie Gemmell created ARTEMIS-4504:
---
Summary: running examples creates unexpected dirs/files (or shows
failure trying)
Key: ARTEMIS-4504
URL: https://issues.apache.org/jira/browse/ARTEMIS-4504
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.31.2
Reporter: Robbie Gemmell
Fix For: 2.32.0
Running one of the examples with e.g mvn verify will typically create and leave
behind an unexpected sub directory within the example source dir called
"${sys:artemis.instance}/log" with [empty] artemis.log and audit.log files
inside. Alternatively, on some systems it may instead fail while trying to do
this and display an error message about it.
This happens because the plugin used by the examples first creates a broker
instance within the target directory, prompting creation of a related
log4j2.properties file, then at the end of the example the plugin is again used
to run the CLI stop command to shut down the broker, the process for which
currently runs the CLI class directly without some of the configuration
properties the CLI script normally sets, and in doing this puts the broker
instance log42.properties file on the classpath and then causes log4j to be
initialised which leads to the erroneous dir+file creation due to the missing
props. We can resolve this by updating the example/plugin to call the CLI
script such that the needed config is actually present.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4492) update logging docs to match current config
[ https://issues.apache.org/jira/browse/ARTEMIS-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4492. - Assignee: Robbie Gemmell Resolution: Fixed > update logging docs to match current config > --- > > Key: ARTEMIS-4492 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4492 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.31.0, 2.31.1, 2.31.2 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > ARTEMIS-4428 updated the default log4j2.properties file to expand some > entries but didnt update the logging docs, which contain some detail around > that file which is now stale as a result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4492) update logging docs to match current config
[ https://issues.apache.org/jira/browse/ARTEMIS-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4492: Priority: Minor (was: Major) > update logging docs to match current config > --- > > Key: ARTEMIS-4492 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4492 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.31.0, 2.31.1, 2.31.2 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.32.0 > > > ARTEMIS-4428 updated the default log4j2.properties file to expand some > entries but didnt update the logging docs, which contain some detail around > that file which is now stale as a result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4492) update logging docs to match current config
[ https://issues.apache.org/jira/browse/ARTEMIS-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4492: Affects Version/s: 2.31.1 2.31.0 > update logging docs to match current config > --- > > Key: ARTEMIS-4492 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4492 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.31.0, 2.31.1, 2.31.2 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > ARTEMIS-4428 updated the default log4j2.properties file to expand some > entries but didnt update the logging docs, which contain some detail around > that file which is now stale as a result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4492) update logging docs to match current config
Robbie Gemmell created ARTEMIS-4492: --- Summary: update logging docs to match current config Key: ARTEMIS-4492 URL: https://issues.apache.org/jira/browse/ARTEMIS-4492 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.31.2 Reporter: Robbie Gemmell Fix For: 2.32.0 ARTEMIS-4428 updated the default log4j2.properties file to expand some entries but didnt update the logging docs, which contain some detail around that file which is now stale as a result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4491) update to activemq 5.18.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4491. - Resolution: Fixed > update to activemq 5.18.3 > - > > Key: ARTEMIS-4491 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4491 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: OpenWire >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (ARTEMIS-4491) update to activemq 5.18.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-4491 started by Robbie Gemmell. --- > update to activemq 5.18.3 > - > > Key: ARTEMIS-4491 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4491 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: OpenWire >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4491) update to activemq 5.18.3
Robbie Gemmell created ARTEMIS-4491: --- Summary: update to activemq 5.18.3 Key: ARTEMIS-4491 URL: https://issues.apache.org/jira/browse/ARTEMIS-4491 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: OpenWire Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4490) update to SLF4J 2.0.9
[ https://issues.apache.org/jira/browse/ARTEMIS-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4490. - Fix Version/s: 2.32.0 Assignee: Robbie Gemmell Resolution: Fixed > update to SLF4J 2.0.9 > - > > Key: ARTEMIS-4490 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4490 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4490) update to SLF4J 2.0.9
Robbie Gemmell created ARTEMIS-4490: --- Summary: update to SLF4J 2.0.9 Key: ARTEMIS-4490 URL: https://issues.apache.org/jira/browse/ARTEMIS-4490 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4489) Update to Karaf 4.4.4
[ https://issues.apache.org/jira/browse/ARTEMIS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4489. - Assignee: Robbie Gemmell Resolution: Fixed > Update to Karaf 4.4.4 > - > > Key: ARTEMIS-4489 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4489 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: osgi >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > Update to Karaf 4.4.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4489) Update to Karaf 4.4.4
Robbie Gemmell created ARTEMIS-4489: --- Summary: Update to Karaf 4.4.4 Key: ARTEMIS-4489 URL: https://issues.apache.org/jira/browse/ARTEMIS-4489 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: osgi Reporter: Robbie Gemmell Fix For: 2.32.0 Update to Karaf 4.4.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4481) CVE-2023-4586 verification
[ https://issues.apache.org/jira/browse/ARTEMIS-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4481. --- Resolution: Information Provided > CVE-2023-4586 verification > -- > > Key: ARTEMIS-4481 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4481 > Project: ActiveMQ Artemis > Issue Type: Task > Components: JMS >Affects Versions: 2.31.2 >Reporter: Pawel Veselov >Priority: Major > > I do apologize for bringing this up here, but it's been a nuisance for us for > a while. > There is an open vulnerability, CVE-2023-4586, discussed here: > https://github.com/netty/netty/issues/8537 > https://github.com/netty/netty/issues/13665 > The only reason we are packaging Netty in one of our applications is because > we package Artemis client/server code as well. > Is it possible to get a published statement from the maintainers of this > project that Artemis doesn't use Netty in an unsecure manner, as stated by > this vulnerability report? > That at least will give justification for continuing to suppress this > vulnerability going forward. > Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4481) CVE-2023-4586 verification
[ https://issues.apache.org/jira/browse/ARTEMIS-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782178#comment-17782178 ] Robbie Gemmell commented on ARTEMIS-4481: - Please ask questions via the mailing list / chat: https://activemq.apache.org/contact I believe the Netty folks are already disputing the recent CVE since they didn't raise it and it is expected/documented behaviour for Netty 4, in the same way the underlying Java SSLEngine at the heart of the issue does not verify hostnames by default either and you must request it be enabled. Artemis configures the hostname verification of the SSLEngine used by Netty based on the _verifyHost_ connector configuration setting. It is true by default for connectors (from 2.18.0 on). https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-netty-ssl You can trivially test the behaviour in order to satisfy yourself that it meets your needs by forcing a hostname mismatch between what you connect to and what the certificate the server is presenting says. > CVE-2023-4586 verification > -- > > Key: ARTEMIS-4481 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4481 > Project: ActiveMQ Artemis > Issue Type: Task > Components: JMS >Affects Versions: 2.31.2 >Reporter: Pawel Veselov >Priority: Major > > I do apologize for bringing this up here, but it's been a nuisance for us for > a while. > There is an open vulnerability, CVE-2023-4586, discussed here: > https://github.com/netty/netty/issues/8537 > https://github.com/netty/netty/issues/13665 > The only reason we are packaging Netty in one of our applications is because > we package Artemis client/server code as well. > Is it possible to get a published statement from the maintainers of this > project that Artemis doesn't use Netty in an unsecure manner, as stated by > this vulnerability report? > That at least will give justification for continuing to suppress this > vulnerability going forward. > Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4478) update to Log4j 2.21.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4478. - Resolution: Fixed > update to Log4j 2.21.1 > -- > > Key: ARTEMIS-4478 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4478 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > update to Log4j 2.21.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4478) update to Log4j 2.21.1
Robbie Gemmell created ARTEMIS-4478: --- Summary: update to Log4j 2.21.1 Key: ARTEMIS-4478 URL: https://issues.apache.org/jira/browse/ARTEMIS-4478 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 update to Log4j 2.21.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4477) artemis-commons does not transform the META-INF/services/javax.json.spi.JsonProvider to the shaded package
[
https://issues.apache.org/jira/browse/ARTEMIS-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4477.
-
Fix Version/s: 2.31.2
Assignee: Robbie Gemmell
Resolution: Fixed
> artemis-commons does not transform the
> META-INF/services/javax.json.spi.JsonProvider to the shaded package
> --
>
> Key: ARTEMIS-4477
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4477
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.31.1
>Reporter: George Gastaldi
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.31.2
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Johnzon is shaded in artemis-common but the
> {{META-INF/services/javax.json.spi.JsonProvider}} included in the
> artemis-commons JAR points to the original class, not the shaded one, causing
> the following error when used as a dependency:
> {code:java}
> Caused by: java.util.ServiceConfigurationError: javax.json.spi.JsonProvider:
> Provider org.apache.johnzon.core.JsonProviderImpl not found
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1212)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1221)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:68)
> at
> io.smallrye.health.SmallRyeHealthReporter.(SmallRyeHealthReporter.java:126)
> at io.smallrye.health.SmallRyeHealthReporter_ClientProxy.(Unknown
> Source)
> at io.smallrye.health.SmallRyeHealthReporter_Bean.proxy(Unknown Source)
> at io.smallrye.health.SmallRyeHealthReporter_Bean.get(Unknown Source)
> at io.smallrye.health.SmallRyeHealthReporter_Bean.get(Unknown Source)
> at io.quarkus.arc.impl.InstanceImpl.getBeanInstance(InstanceImpl.java:229)
> at io.quarkus.arc.impl.InstanceImpl.getInternal(InstanceImpl.java:215)
> at io.quarkus.arc.impl.InstanceImpl.get(InstanceImpl.java:100)
> at
> io.quarkus.smallrye.health.runtime.SmallRyeHealthRecorder.processSmallRyeHealthRuntimeConfiguration(SmallRyeHealthRecorder.java:47)
> at
> io.quarkus.deployment.steps.SmallRyeHealthProcessor$processSmallRyeHealthRuntimeConfig1687788508.deploy_0(Unknown
> Source)
> at
> io.quarkus.deployment.steps.SmallRyeHealthProcessor$processSmallRyeHealthRuntimeConfig1687788508.deploy(Unknown
> Source)
> ... 53 more
> {code}
> This bug seems to have been introduced in
> [https://github.com/apache/activemq-artemis/commit/3392d084a904f9517a30242facb0159cf94fbc87]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4474) Update to Zookeeper 3.8.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4474. - Resolution: Fixed > Update to Zookeeper 3.8.3 > - > > Key: ARTEMIS-4474 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4474 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > Update to Zookeeper 3.8.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4474) Update to Zookeeper 3.8.3
Robbie Gemmell created ARTEMIS-4474: --- Summary: Update to Zookeeper 3.8.3 Key: ARTEMIS-4474 URL: https://issues.apache.org/jira/browse/ARTEMIS-4474 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.32.0 Update to Zookeeper 3.8.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1662#comment-1662
]
Robbie Gemmell commented on ARTEMIS-4462:
-
The 5.x broker accepting the message because it isnt currently decoding it for
what you are doing, doesnt mean the payload is actually valid to its
expectations. It just means it isnt currently doing anything that makes it
notice that it isnt.
There are numerous uses of ActiveMQTextMessage in the overall broker ActiveMQ
5.x codebase. If you go and look at the management bits in the broker module
you will find it using ActiveMQTextMessage and calling getText(), which will do
a UTF-8 decode using the very same
org.apache.activemq.util.MarshallingSupport.readUTF8() method that Artemis is
using; i.e the 5.x broker does expect the OpenWire TextMessage payload to be
UTF-8. The openwire-legacy module used by the 5.x broker, has numerous uses of
the ActiveMQTextMessage class. The 5.x brokers various protocol modules use
ActiveMQTextMessage to handle the OpenWire text message, involving explicit
retrievals of strings that will be UTF-8 decoded using that very same method,
since the 5.x broker does expect OpenWire TextMessage to have UTF8 payload. The
java activemq-client module is essentially the defacto OpenWire reference
implementation and it clearly shows its expected an OpenWire TextMessage
payload is UTF8.
In any case, as Artemis operates it needs to read the OpenWire TextMessage
payload, and it does so using that OpenWire impl from the 5.x activemq-client,
meaning it will do so using UTF-8 the same way that 5.x client and broker do
since its expected OpenWire TextMessage payloads are valid UTF-8 encodings.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1159#comment-1159
]
Robbie Gemmell commented on ARTEMIS-4462:
-
As both Tim and I have now said, its probable you aren't seeing an issue on 5.x
broker because you aren't currently doing anything that needs it to decode the
content there. That doesnt mean the content is valid.
Yes, the 5.x broker uses the activemq-client module (as does artemis), as much
of the openwire impl is in the activemq-client module.
I know you are not using activemq-client in your application however I
referenced it to show that the expectation from it, used in the broker and java
client, is that the OpenWire TextMessage payload is UTF-8. If you want to send
non-UTF8 payloads you should probably be using the BytesMessage type instead
where you can send whatever bytes you prefer.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1135#comment-1135
]
Robbie Gemmell commented on ARTEMIS-4462:
-
As Tim mentioned, it can perhaps sneak through the 5.x broker if nothing is
done that needs the message to be decoded, but would likely blow up if it were.
The 5.x broker and client do actually expect OpenWire TextMessages to be
encoded in UTF-8:
[https://github.com/apache/activemq/blob/activemq-5.18.2/activemq-client/src/main/java/org/apache/activemq/command/ActiveMQTextMessage.java#L101]
[https://github.com/apache/activemq/blob/activemq-5.18.2/activemq-client/src/main/java/org/apache/activemq/command/ActiveMQTextMessage.java#L144]
Artemis isnt 'trying to validate the message', it is simply storing it in its
native message format which it reads the message to do so. That decoding, which
is actually being performed by code from activemq-client as used by the 5.x
client/broker, then encountered that it couldnt decode the payload and threw.
It seems like BytesMessages would be far more appropriate for your use case
where you expect to control the payload encoding at the producer and consumer
sides.
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: ARTEMIS-4462
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4462
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Liviu Citu
>Priority: Major
>
> When a text message non-UTF-8 (ISO-8859-15) containing special characters is
> sent from ActiveMQ CPP client to Artemis, an exception
> "java.io.UTFDataFormatException" is seen in Artemis server log.
> Although the exception is thrown as a warning, the message gets rejected by
> the server.
> Below the Artemis server log:
>
> {noformat}
> 2023-09-29 11:34:32,736 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
>
> java.io.UTFDataFormatException: null
> at
> org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769)
> ~[activemq-client-5.17.2.jar:5.17.2]
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.30.0.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.30.0.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> [?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.30.0.jar:?]
> 2023-09-29 11:34:32,753 WARN
> [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection]
> Errors occurred during the buffering operation
> org.apache.activemq.artemis.api.core.ActiveMQException: null
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674)
>
[jira] [Resolved] (ARTEMIS-4457) Upgrade jetty version to 10.0.16
[ https://issues.apache.org/jira/browse/ARTEMIS-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4457. - Fix Version/s: 2.32.0 Resolution: Fixed > Upgrade jetty version to 10.0.16 > > > Key: ARTEMIS-4457 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4457 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.32.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4454) Upgrade Netty to 4.1.99.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4454: - Assignee: (was: Justin Bertram) > Upgrade Netty to 4.1.99.Final > - > > Key: ARTEMIS-4454 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4454 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Fix For: 2.30.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4454) Upgrade Netty to 4.1.99.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4454. --- Resolution: Duplicate > Upgrade Netty to 4.1.99.Final > - > > Key: ARTEMIS-4454 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4454 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4454) Upgrade Netty to 4.1.99.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4454: Fix Version/s: (was: 2.30.0) > Upgrade Netty to 4.1.99.Final > - > > Key: ARTEMIS-4454 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4454 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4451) non-SASL AMQP connection fails if resource audit logging enabled
[ https://issues.apache.org/jira/browse/ARTEMIS-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4451. - Assignee: Robbie Gemmell Resolution: Fixed > non-SASL AMQP connection fails if resource audit logging enabled > > > Key: ARTEMIS-4451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4451 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.31.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > If the resource audit logging is enabled, then previous connection related > audit log changes cause non-SASL AMQP connections to always fail, with the > broker indicating to the client that a SASL connection is required, even if > the broker config is actually such that it should not be. Simply disabling > the resource audit log in the logging config then allows the non-SASL > connection to succeed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4451) non-SASL AMQP connection fails if resource audit logging enabled
[ https://issues.apache.org/jira/browse/ARTEMIS-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4451: Description: If the resource audit logging is enabled, then previous connection related audit log changes cause non-SASL AMQP connections to always fail, with the broker indicating to the client that a SASL connection is required, even if the broker config is actually such that it should not be. Simply disabling the resource audit log in the logging config then allows the non-SASL connection to succeed. (was: If the resource audit logging is enabled, then recent connection related log additions cause non-SASL AMQP connections to always fail, with the broker indicating to the client that a SASL connection is required, even if the broker config is actually such that it should not be. Simply disabling the resource audit log in the logging config then allows the non-SASL connection to succeed.) > non-SASL AMQP connection fails if resource audit logging enabled > > > Key: ARTEMIS-4451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4451 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.31.0 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > If the resource audit logging is enabled, then previous connection related > audit log changes cause non-SASL AMQP connections to always fail, with the > broker indicating to the client that a SASL connection is required, even if > the broker config is actually such that it should not be. Simply disabling > the resource audit log in the logging config then allows the non-SASL > connection to succeed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4451) non-SASL AMQP connection fails if resource audit logging enabled
Robbie Gemmell created ARTEMIS-4451: --- Summary: non-SASL AMQP connection fails if resource audit logging enabled Key: ARTEMIS-4451 URL: https://issues.apache.org/jira/browse/ARTEMIS-4451 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.31.0 Reporter: Robbie Gemmell Fix For: 2.32.0 If the resource audit logging is enabled, then recent connection related log additions cause non-SASL AMQP connections to always fail, with the broker indicating to the client that a SASL connection is required, even if the broker config is actually such that it should not be. Simply disabling the resource audit log in the logging config then allows the non-SASL connection to succeed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9309) Drop 32-bit support
[ https://issues.apache.org/jira/browse/AMQ-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770182#comment-17770182 ] Robbie Gemmell commented on AMQ-9309: - Java 17 (and 18 and 19) 32-bit support is fairly easily available from Temurin: https://adoptium.net/en-GB/temurin/releases/?arch=x86 However thats only for Windows though (and they dropped x86 Windows builds from JDK 20: https://adoptium.net/en-GB/temurin/releases/?arch=x86=20). Windows 11 also dropped 32bit support. So it does seem a reasonable time to drop it even if there is some availability still. > Drop 32-bit support > --- > > Key: AMQ-9309 > URL: https://issues.apache.org/jira/browse/AMQ-9309 > Project: ActiveMQ > Issue Type: Task >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Major > Fix For: 6.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > From JDK 10 and on, Oracle (and most other JDK vendors), dropped support for > 32-bit JDK builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4433) improve Reproducible Builds
[ https://issues.apache.org/jira/browse/ARTEMIS-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4433. - Assignee: Robbie Gemmell Resolution: Fixed > improve Reproducible Builds > --- > > Key: ARTEMIS-4433 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4433 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.31.0 >Reporter: Herve Boutemy >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.32.0 > > > there are 2 issues easy to fix: > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/activemq/artemis/README.md > - dependency-reduced-pom.xml stored in source-release archives > - old maven-rar-plugin > we'll see later for the remaining ones: we need to go step by step -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4431) AMQP federated address consumer not applying hops annotation correctly
[ https://issues.apache.org/jira/browse/ARTEMIS-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4431: Fix Version/s: 2.32.0 (was: 2.31.0) Affects Version/s: 2.31.0 (was: 2.30.0) > AMQP federated address consumer not applying hops annotation correctly > -- > > Key: ARTEMIS-4431 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4431 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.31.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.32.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The AMQP federation address consumer omits a call to re-encode the message > after updating the hops annotation that track how many federation links the > message has traversed. This results in the message not carrying forward the > correct annotation which breaks the max hops configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4417) AbstractJournalStorageManager storeKeyValuePair + deleteKeyValuePair are not thread safe
Robbie Gemmell created ARTEMIS-4417: --- Summary: AbstractJournalStorageManager storeKeyValuePair + deleteKeyValuePair are not thread safe Key: ARTEMIS-4417 URL: https://issues.apache.org/jira/browse/ARTEMIS-4417 Project: ActiveMQ Artemis Issue Type: Bug Components: Balancer Affects Versions: 2.30.0 Reporter: Robbie Gemmell Fix For: 2.31.0 Continuing on from ARTEMIS-4406, the calls to AbstractJournalStorageManager storeKeyValuePair + deleteKeyValuePair used by LocalCache as part of the connection-router implementation are themselves also not entirely thread safe. A ConcurrentHashMap is used for the initial structure, however a regular HashMap sub-map is then stored within the concurrent outer map, which can then also be accessed concurrently, meaning the methods aren't currently thread safe; it also needs to be a ConcurrentHashMap. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4410) Openwire prefetched messages can be out of order after failover to an exclusive queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4410. - Resolution: Fixed > Openwire prefetched messages can be out of order after failover to an > exclusive queue > - > > Key: ARTEMIS-4410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.31.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > related to ARTEMIS-4284 but when the connection drops, and the client > reconnects. Any inflight messages can be addSorted to the queue, but any new > consumer on a newly created connection can see the queue without certainty > that prefetched are added back. > with an exclusive queue, the order should be preserved for each successive > exclusive consumer. > The default prefetch means this is typical with openwire, but the visibility > of delivered messages is not unique to that protocol. With any unacked > messages that exceed credit this can occur in the event of unclean disconnect > and reconnect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4396) Make address/queue "internal" property durable
[ https://issues.apache.org/jira/browse/ARTEMIS-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4396. - Fix Version/s: 2.31.0 Resolution: Fixed > Make address/queue "internal" property durable > -- > > Key: ARTEMIS-4396 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4396 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.31.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4413) CheckTest.testNodeCheckTopology fails sporadically
Robbie Gemmell created ARTEMIS-4413: --- Summary: CheckTest.testNodeCheckTopology fails sporadically Key: ARTEMIS-4413 URL: https://issues.apache.org/jira/browse/ARTEMIS-4413 Project: ActiveMQ Artemis Issue Type: Test Affects Versions: 2.31.0 Reporter: Robbie Gemmell CheckTest.testNodeCheckTopology fails sporadically in CI, due to a thread leak from shutdown issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4412) openwire TwoBrokerFailoverClusterTest test fails sporadically
[ https://issues.apache.org/jira/browse/ARTEMIS-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4412. - Resolution: Fixed > openwire TwoBrokerFailoverClusterTest test fails sporadically > - > > Key: ARTEMIS-4412 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4412 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > > The openwire TwoBrokerFailoverClusterTest test fails sporadically. It is > balancing 30 connections between 2 brokers with randomized connect, and fails > if <35% hit one node. I've only seen it fail because 33.33% hit one node, i.e > the difference between 10 and 11 connections. It doesnt seem that anything in > play ensures >= 35% actually end up on one node, and the test is just making > a slightly optimistic take on what randomizing between 2 things could do. > Make it a bit less optimistic to help cut out the sporadic failures while > still validating there is a spread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4412) openwire TwoBrokerFailoverClusterTest test fails sporadically
Robbie Gemmell created ARTEMIS-4412: --- Summary: openwire TwoBrokerFailoverClusterTest test fails sporadically Key: ARTEMIS-4412 URL: https://issues.apache.org/jira/browse/ARTEMIS-4412 Project: ActiveMQ Artemis Issue Type: Test Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.31.0 The openwire TwoBrokerFailoverClusterTest test fails sporadically. It is balancing 30 connections between 2 brokers with randomized connect, and fails if <35% hit one node. I've only seen it fail because 33.33% hit one node, i.e the difference between 10 and 11 connections. It doesnt seem that anything in play ensures >= 35% actually end up on one node, and the test is just making a slightly optimistic take on what randomizing between 2 things could do. Make it a bit less optimistic to help cut out the sporadic failures while still validating there is a spread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4355) Update to Сurator 5.5.0 and Zookeeper 3.8.2
[ https://issues.apache.org/jira/browse/ARTEMIS-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4355. - Fix Version/s: 2.31.0 Resolution: Fixed > Update to Сurator 5.5.0 and Zookeeper 3.8.2 > --- > > Key: ARTEMIS-4355 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4355 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Clustering >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 5h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4355) Update to Сurator 5.5.0 and Zookeeper 3.8.2
[ https://issues.apache.org/jira/browse/ARTEMIS-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4355: Summary: Update to Сurator 5.5.0 and Zookeeper 3.8.2 (was: Update Сurator to 5.5.0; Zookeeper 3.8.2) > Update to Сurator 5.5.0 and Zookeeper 3.8.2 > --- > > Key: ARTEMIS-4355 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4355 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Clustering >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Minor > Time Spent: 5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349 ] Robbie Gemmell deleted comment on ARTEMIS-4349: - was (Author: gemmellr): Discussion continued on the PR(s) and it was decided to switch the brokers cache usage to Caffeine for additional reasons such as Guava itself recommending Caffeine is used, and the seemingly more active community/maintenance/etc. Other parts of the code base do still use Guava (e.g console, quorum-ri via curator-client, tests), but the actual artemis-server broker itself doesnt directly any more and switches to Caffeine instead. > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.31.0 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4349. - Assignee: Robbie Gemmell Resolution: Fixed > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.31.0 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4349) Replace Guava cache with Caffeine
[jira] [Updated] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4349: Affects Version/s: 2.30.0 (was: 2.29.0) > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759992#comment-17759992 ] Robbie Gemmell commented on ARTEMIS-4349: - Discussion continued on the PR(s) and it was decided to switch the brokers cache usage to Caffeine for additional reasons such as Guava itself recommending Caffeine is used, and the seemingly more active community/maintenance/etc. Other parts of the code base do still use Guava (e.g console, quorum-ri via curator-client, tests), but the actual artemis-server broker itself doesnt directly any more and switches to Caffeine instead. > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4349) Replace Guava cache with Caffeine
[ https://issues.apache.org/jira/browse/ARTEMIS-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759993#comment-17759993 ] Robbie Gemmell commented on ARTEMIS-4349: - Discussion continued on the PR(s) and it was decided to switch the brokers cache usage to Caffeine for additional reasons such as Guava itself recommending Caffeine is used, and the seemingly more active community/maintenance/etc. Other parts of the code base do still use Guava (e.g console, quorum-ri via curator-client, tests), but the actual artemis-server broker itself doesnt directly any more and switches to Caffeine instead. > Replace Guava cache with Caffeine > - > > Key: ARTEMIS-4349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4349 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > > based on benchmark https://github.com/ben-manes/caffeine/wiki/Benchmarks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4405) Incorrect username logging in AMQ601264 events
[
https://issues.apache.org/jira/browse/ARTEMIS-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4405.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> Incorrect username logging in AMQ601264 events
> --
>
> Key: ARTEMIS-4405
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4405
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Aleksandr Milovidov
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.31.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We have ActiveMQ Artemis with audit logging turned on, and sometimes wrong
> username is logged when user gets an authorization error (audit log event
> AMQ601264). I have reproduced this issue when client uses STOMP to connect to
> the broker. In that case client username is always logged as anonymous, and
> source IP address seems to be correct.
> We have a lot of other audit log messages where different usernames are
> logged in single log event, but I cannot attach these logs because it
> contains sensitive information. I think this problem is not specific to STOMP
> clients because most our clients use core and openwire. I will try to
> reproduce it later.
> The problem is not specific to the current version of Artemis.
> Steps to reproduce (for STOMP client):
> 1. Create Artemis instance
> {{artemis create --user admin --password admin --require-login }}
> Edit {{artemis-roles.properties}} and {{artemis-users.properties}} to create
> some other user with password and non-admin role. For example, add string
> {{alice = alice}} to both files.
> Edit log4j2.properties to enable base audit logging:
> {code:java}
> logger.audit_base = INFO, audit_log_file{code}
> To connect to the broker with STOMP I have used python with Stompest library
> (it has to be installed using pip install stompest).
> Example STOMP producer python code (it does not handle authorization errors):
>
> {code:java}
> from stompest.config import StompConfig
> from stompest.protocol import StompSpec
> from stompest.sync import Stomp
> CONFIG = StompConfig("tcp://localhost:61613", login="alice",
> passcode="alice", version=StompSpec.VERSION_1_0)
> QUEUE = 'test.queue'
> client = Stomp(CONFIG)
> client.connect()
> client.send(QUEUE, 'Test message'.encode())
> client.disconnect()
> {code}
> Run this example code. Check broker audit.log. For example:
>
> {code:java}
> 2023-08-28 17:39:20,042 [AUDIT](Thread-1 (activemq-netty-threads)) AMQ601267:
> User alice(alice)@127.0.0.1:56685 is creating a core session on target
> resource ActiveMQServerImpl::name=0.0.0.0 with parameters:
> [ac22db0e-45b0-11ee-b333-005056abe8b9, alice, , 102400,
> org.apache.activemq.artemis.core.protocol.stomp.StompConnection@3313e538,
> true, false, false, false, null,
> org.apache.activemq.artemis.core.protocol.stomp.StompSession@2fc820ee, true,
> {}]
> 2023-08-28 17:39:20,081 [AUDIT](Thread-1 (activemq-netty-threads)) AMQ601262:
> User alice(alice)@127.0.0.1:56685 is creating address on target resource:
> ac22db0e-45b0-11ee-b333-005056abe8b9 with parameters: [Address
> [name=test.queue, id=0, routingTypes={MULTICAST}, autoCreated=false,
> paused=false, bindingRemovedTimestamp=-1, swept=false,
> createdTimestamp=1693233560081], true]
> 2023-08-28 17:39:20,116 [AUDIT](Thread-1 (activemq-netty-threads)) AMQ601264:
> User anonymous@127.0.0.1:56685 gets security check failure, reason =
> AMQ229032: User: alice does not have permission='CREATE_ADDRESS' on address
> test.queue
> org.apache.activemq.artemis.api.core.ActiveMQSecurityException: AMQ229032:
> User: alice does not have permission='CREATE_ADDRESS' on address test.queue
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:305)
> [artemis-server-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:227)
> [artemis-server-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.securityCheck(ServerSessionImpl.java:503)
> [artemis-server-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createAddress(ServerSessionImpl.java:972)
> [artemis-server-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createAddress(ServerSessionImpl.java:962)
> [artemis-server-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.stomp.StompConnection.autoCreateDestinationIfPossible(StompConnection.java:184)
> [artemis-stomp-protocol-2.30.0.jar:2.30.0]
> at
> org.apache.activemq.artemis.core.protocol.stomp.VersionedStompFrameHandler.onSend(VersionedStompFrameHandler.java:188)
>
[jira] [Resolved] (ARTEMIS-4406) connection router LocalCache persisted entry tracking is not thread safe
[ https://issues.apache.org/jira/browse/ARTEMIS-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4406. - Resolution: Fixed > connection router LocalCache persisted entry tracking is not thread safe > > > Key: ARTEMIS-4406 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4406 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Balancer >Affects Versions: 2.30.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.31.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The persistedCacheEntries map within LocalCache used to track persisted > entries for the connection router is a regular HashMap and so is not thread > safe, but it may be updated concurrently. Switch it to using a > ConcurrentHashMap. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4406) connection router LocalCache persisted entry tracking is not thread safe
Robbie Gemmell created ARTEMIS-4406: --- Summary: connection router LocalCache persisted entry tracking is not thread safe Key: ARTEMIS-4406 URL: https://issues.apache.org/jira/browse/ARTEMIS-4406 Project: ActiveMQ Artemis Issue Type: Bug Components: Balancer Affects Versions: 2.30.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.31.0 The persistedCacheEntries map within LocalCache used to track persisted entries for the connection router is a regular HashMap and so is not thread safe, but it may be updated concurrently. Switch it to using a ConcurrentHashMap. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4402) add unit tests to exercise semi-generated LogBundle code more directly
[ https://issues.apache.org/jira/browse/ARTEMIS-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4402. - Resolution: Fixed > add unit tests to exercise semi-generated LogBundle code more directly > -- > > Key: ARTEMIS-4402 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4402 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > > Add unit tests to exercise the semi-generated LogBundle related code more > directly, showing up issues in the generation quicker/more-specifically for > given modules, rather than relying on failures that occur when running much > of the wider more general client+broker test suite (though a lot of which > aren't run in the PR test jobs). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4402) add unit tests to exercise semi-generated LogBundle code more directly
Robbie Gemmell created ARTEMIS-4402: --- Summary: add unit tests to exercise semi-generated LogBundle code more directly Key: ARTEMIS-4402 URL: https://issues.apache.org/jira/browse/ARTEMIS-4402 Project: ActiveMQ Artemis Issue Type: Test Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.31.0 Add unit tests to exercise the semi-generated LogBundle related code more directly, showing up issues in the generation quicker/more-specifically for given modules, rather than relying on failures that occur when running much of the wider more general client+broker test suite (though a lot of which aren't run in the PR test jobs). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4399) Authentication cache set to size 0 (i.e. disabled) is not threadsafe
[
https://issues.apache.org/jira/browse/ARTEMIS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4399.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> Authentication cache set to size 0 (i.e. disabled) is not threadsafe
> -
>
> Key: ARTEMIS-4399
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Rich T
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that
> even with size 0 an entry is added but then is removed; this means that
> another thread can end up pulling an entry out of the cache before it is
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded
> into the cache. This can be useful in testing, or to disable caching
> temporarily without a code change.This feature cannot be used in conjunction
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is
> requested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4400. - Assignee: Robbie Gemmell Resolution: Fixed > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Description: The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on artemis-unit-test-support from test scope to compile scope, but it should clearly be in test scope so swap it back. (was: The changes in ARTEMIS-4353 incorrectly swapped ) > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > > The changes in ARTEMIS-4353 changed the artemis-cdi-client dependency on > artemis-unit-test-support from test scope to compile scope, but it should > clearly be in test scope so swap it back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Description: The changes in ARTEMIS-4353 incorrectly swapped > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > > The changes in ARTEMIS-4353 incorrectly swapped -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Fix Version/s: 2.31.0 > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4400) artemis-cdi-client: artemis-unit-test-support should be in test scope
[ https://issues.apache.org/jira/browse/ARTEMIS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4400: Summary: artemis-cdi-client: artemis-unit-test-support should be in test scope (was: artemis-cdi-client: artemis-unit-test-support in test scope) > artemis-cdi-client: artemis-unit-test-support should be in test scope > - > > Key: ARTEMIS-4400 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4400 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Alexey Markevich >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4395) Upgrade example spring-boot-plugin version to 2.6.15
[ https://issues.apache.org/jira/browse/ARTEMIS-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4395: Summary: Upgrade example spring-boot-plugin version to 2.6.15 (was: Upgrade spring-boot-plugin version to 2.6.15) > Upgrade example spring-boot-plugin version to 2.6.15 > > > Key: ARTEMIS-4395 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4395 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4395) Upgrade example spring-boot-plugin version to 2.6.15
[ https://issues.apache.org/jira/browse/ARTEMIS-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4395. - Fix Version/s: 2.31.0 Resolution: Fixed > Upgrade example spring-boot-plugin version to 2.6.15 > > > Key: ARTEMIS-4395 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4395 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.31.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4394) management console war file contains some duplicate jars
[ https://issues.apache.org/jira/browse/ARTEMIS-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4394. - Resolution: Fixed > management console war file contains some duplicate jars > > > Key: ARTEMIS-4394 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4394 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > > The management console.war file contains some 'duplicate' lib jars due to the > way the console module build works. As part of its creation it repackages the > hawtio war, removing some logging deps + config the broker supplies, and also > updating the contained guava version to match the current managed version > used elsewhere in the codebase. For the latter process, some transitive > dependencies are being duplicated with both the original and updated versions > then being present in the new war. As these are mainly build time related > annotation dependencies, which we actually exclude elsewhere in the build, it > is likely not problematic; however it still shouldn't be the case. Update the > process to exclude the originals and so use only the newer replacement > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4394) management console war file contains some duplicate jars
Robbie Gemmell created ARTEMIS-4394: --- Summary: management console war file contains some duplicate jars Key: ARTEMIS-4394 URL: https://issues.apache.org/jira/browse/ARTEMIS-4394 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.30.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.31.0 The management console.war file contains some 'duplicate' lib jars due to the way the console module build works. As part of its creation it repackages the hawtio war, removing some logging deps + config the broker supplies, and also updating the contained guava version to match the current managed version used elsewhere in the codebase. For the latter process, some transitive dependencies are being duplicated with both the original and updated versions then being present in the new war. As these are mainly build time related annotation dependencies, which we actually exclude elsewhere in the build, it is likely not problematic; however it still shouldn't be the case. Update the process to exclude the originals and so use only the newer replacement version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4394) management console war file contains some duplicate jars
[ https://issues.apache.org/jira/browse/ARTEMIS-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4394: Priority: Minor (was: Major) > management console war file contains some duplicate jars > > > Key: ARTEMIS-4394 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4394 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.30.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > > The management console.war file contains some 'duplicate' lib jars due to the > way the console module build works. As part of its creation it repackages the > hawtio war, removing some logging deps + config the broker supplies, and also > updating the contained guava version to match the current managed version > used elsewhere in the codebase. For the latter process, some transitive > dependencies are being duplicated with both the original and updated versions > then being present in the new war. As these are mainly build time related > annotation dependencies, which we actually exclude elsewhere in the build, it > is likely not problematic; however it still shouldn't be the case. Update the > process to exclude the originals and so use only the newer replacement > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752093#comment-17752093 ] Robbie Gemmell commented on AMQ-9297: - Its not something I am working on...but at the previously referenced links, such as the specific PR for the changes you are interested in, you might have found useful comments like: [https://github.com/apache/activemq/pull/996#issuecomment-1658481899] and [https://github.com/apache/activemq/pull/996#issuecomment-1660329766] > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9295) activemq-jakarta-pool - A connection pool for Jakarta JMS API
[ https://issues.apache.org/jira/browse/AMQ-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751992#comment-17751992 ] Robbie Gemmell commented on AMQ-9295: - I believe activemq-jms-pool conversion is already included in the ongoing Jakarta work for ActiveMQ 5.19.x being done under AMQ-9239 (e.g https://github.com/apache/activemq/pull/996) (Aside: Pooled JMS is not simply 'the JMS pool for Artemis', it was specifically created for enabling usage with other JMS 2 or now Jakarta Messaging 3 clients) > activemq-jakarta-pool - A connection pool for Jakarta JMS API > - > > Key: AMQ-9295 > URL: https://issues.apache.org/jira/browse/AMQ-9295 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > > The current activemq-pool is javax JMS based and does not work with Jakarta > JMS APIs. > The JMS pool for Artemis can be used instead as it supports Jakarta JMS APIs > https://github.com/messaginghub/pooled-jms > And with this factory > org.messaginghub.pooled.jms.JmsPoolConnectionFactory > However this and activemq-pool does not offer same features and configuration > names. So for users that want to use ActiveMQ 5.x but with Jakarta JMS APIs > then it would be good to do a activemq-jakarta-pool so they can easily > upgrade and use the same pool as before. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751985#comment-17751985 ] Robbie Gemmell edited comment on AMQ-9297 at 8/8/23 10:06 AM: -- As explained on the [users list thread|https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] the 5.18.x zip distribution is still entirely javax.jms API package based, so this is expected. Only the separate transitional activemq-client-jakarta module is jakarta.jms API package based. For more, see: - [https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] - [https://activemq.apache.org/jms2] - AMQ-9239 - [https://github.com/apache/activemq/pull/996] was (Author: gemmellr): As explained on the [users list thread|https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] the 5.18.x zip distribution is still entirely javax.jms API package based, so this is expected. Only the separate transitional activemq-client-jakarta module is jakarta.jms API package based. For more, see [https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo], [https://activemq.apache.org/jms2], AMQ-9239, [https://github.com/apache/activemq/pull/996] > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed AMQ-9297. --- Resolution: Invalid > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751985#comment-17751985 ] Robbie Gemmell edited comment on AMQ-9297 at 8/8/23 10:05 AM: -- As explained on the [users list thread|https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] the 5.18.x zip distribution is still entirely javax.jms API package based, so this is expected. Only the separate transitional activemq-client-jakarta module is jakarta.jms API package based. For more, see [https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo], [https://activemq.apache.org/jms2], AMQ-9239, [https://github.com/apache/activemq/pull/996] was (Author: gemmellr): As explained on the (users list thread)[https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] the 5.18.x zip distribution is still entirely javax.jms API package based, so this is expected. Only the separate transitional activemq-client-jakarta module is jakarta.jms API package based. For more, see [https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo], [https://activemq.apache.org/jms2], AMQ-9239, [https://github.com/apache/activemq/pull/996] > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened AMQ-9297: - > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (AMQ-9297) Activemq jakarta namespace support still depends on some javax.jms packages
[ https://issues.apache.org/jira/browse/AMQ-9297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed AMQ-9297. --- Resolution: Invalid As explained on the (users list thread)[https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo] the 5.18.x zip distribution is still entirely javax.jms API package based, so this is expected. Only the separate transitional activemq-client-jakarta module is jakarta.jms API package based. For more, see [https://lists.apache.org/thread/yvqmftv5nv975h9h8lwvwm4wowb8mhdo], [https://activemq.apache.org/jms2], AMQ-9239, [https://github.com/apache/activemq/pull/996] > Activemq jakarta namespace support still depends on some javax.jms packages > --- > > Key: AMQ-9297 > URL: https://issues.apache.org/jira/browse/AMQ-9297 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.18.2 >Reporter: Jayeshkumar >Priority: Major > > Hello, > I am currently moving from 5.16.5 version to activemq 5.18.2 which has > support for jakarta namespace, however there are still references to old > javax packages, I am getting ClassNotFoundException for > javax.jms.JMSException, but the right package should be jakarta.jms which is > already present > In the 5.18.2 zip distribution, I see jakarta-jms-api-2.X is used for which > the underlying package is still javax and not jakarta. Rather to fully > support jakarta namespace, we should plan and move to jakarta-jms-3.X which > has the right package structure. Any reference to javax.jms should be > replaced to use the new namespace > So the existing support needs some more work before we can use it seamlessly. > Can you please review and share your views on this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4386) consolidate used servlet-api deps
[ https://issues.apache.org/jira/browse/ARTEMIS-4386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4386. - Assignee: Robbie Gemmell Resolution: Fixed > consolidate used servlet-api deps > - > > Key: ARTEMIS-4386 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4386 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.31.0 > > > The build is currently using multiple servlet API deps, and the broker > assembly archive even includes a couple. They can be consolidated on one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4386) consolidate used servlet-api deps
Robbie Gemmell created ARTEMIS-4386: --- Summary: consolidate used servlet-api deps Key: ARTEMIS-4386 URL: https://issues.apache.org/jira/browse/ARTEMIS-4386 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Fix For: 2.31.0 The build is currently using multiple servlet API deps, and the broker assembly archive even includes a couple. They can be consolidated on one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4259.
---
Resolution: Fixed
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics, leading to no filtering occurring. For AMQP, the consumer is filtered
> by the broker but the subscription queue is not, leading to retention of
> non-matching messages.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4259:
Description:
The CORE protocol does not honor consumers with a filter when used on FQQN
topics, leading to no filtering occurring. For AMQP, the consumer is filtered
by the broker but the subscription queue is not, leading to retention of
non-matching messages.
Steps to reproduce:
Start a consumer using CLI:
{noformat}
./artemis consumer --url tcp://localhost:61616 --destination
topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
"foo='bar'" --verbose{noformat}
Send a message without the filter string:
{noformat}
./artemis producer --url tcp://localhost:61616 --destination
topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message "some
text"{noformat}
You can observe the CORE client consuming the message which does not contain
the filter String:
{noformat}
Connection brokerURL = tcp://localhost:61616
Consumer:: filter = foo='bar'
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
are consumed
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
Received text sized at 9
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in second
: 8 s
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
second : 8140 milli seconds
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
finished{noformat}
was:
The CORE protocol does not honor consumers with a filter when used on FQQN
topics.
Steps to reproduce:
Start a consumer using CLI:
{noformat}
./artemis consumer --url tcp://localhost:61616 --destination
topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
"foo='bar'" --verbose{noformat}
Send a message without the filter string:
{noformat}
./artemis producer --url tcp://localhost:61616 --destination
topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message "some
text"{noformat}
You can observe the CORE client consuming the message which does not contain
the filter String:
{noformat}
Connection brokerURL = tcp://localhost:61616
Consumer:: filter = foo='bar'
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
are consumed
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
Received text sized at 9
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in second
: 8 s
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
second : 8140 milli seconds
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
finished{noformat}
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics, leading to no filtering occurring. For AMQP, the consumer is filtered
> by the broker but the subscription queue is not, leading to retention of
> non-matching messages.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
>
[jira] [Reopened] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4259:
-
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4380) Multiple Failover Failback example missing
[ https://issues.apache.org/jira/browse/ARTEMIS-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4380: Fix Version/s: (was: 2.30.0) > Multiple Failover Failback example missing > -- > > Key: ARTEMIS-4380 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4380 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Geert Schuring >Priority: Major > Labels: examples, failback > > The code for example "Multiple Failover Failback" is the exact same as > "Multiple Failover" while it should show how to make sure clients revert back > to the master broker as soon as it comes back online. > Compare these two: > # > [https://raw.githubusercontent.com/apache/activemq-artemis/main/examples/features/ha/multiple-failover/src/main/java/org/apache/activemq/artemis/jms/example/MultipleFailoverExample.java] > # > [https://raw.githubusercontent.com/apache/activemq-artemis/main/examples/features/ha/multiple-failover-failback/src/main/java/org/apache/activemq/artemis/jms/example/MultipleFailoverFailbackExample.java] > There's no meaningfull difference between them, unless I'm misunderstanding > something. In any case, the axample does not tell me how to achieve failback. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4374) Pax Exam 4.13.5
[ https://issues.apache.org/jira/browse/ARTEMIS-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4374. - Fix Version/s: 2.31.0 Resolution: Fixed > Pax Exam 4.13.5 > --- > > Key: ARTEMIS-4374 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4374 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: osgi >Affects Versions: 2.29.0 >Reporter: Alexey Markevich >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4373) Upgrade Karaf to 4.4.3
[
https://issues.apache.org/jira/browse/ARTEMIS-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4373:
Description:
PR builds on JDK 20 (seemingly beginning with 20.0.2) recently started failing
with:
{noformat}
Error: Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project
artemis-features: Execution verify of goal
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required
class was missing while executing
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify:
org/apache/karaf/features/internal/download/DownloadManager{noformat}
Moving to 4.4.3 resolves the issue. PR builds are able to finish normally.
was:
PR builds on JDK 20 recently started failing with:
{noformat}
Error: Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project
artemis-features: Execution verify of goal
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required
class was missing while executing
org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify:
org/apache/karaf/features/internal/download/DownloadManager{noformat}
Moving to 4.4.3 resolves the issue. PR builds are able to finish normally.
> Upgrade Karaf to 4.4.3
> --
>
> Key: ARTEMIS-4373
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4373
> Project: ActiveMQ Artemis
> Issue Type: Dependency upgrade
>Affects Versions: 2.30.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PR builds on JDK 20 (seemingly beginning with 20.0.2) recently started
> failing with:
> {noformat}
> Error: Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project
> artemis-features: Execution verify of goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required
> class was missing while executing
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify:
> org/apache/karaf/features/internal/download/DownloadManager{noformat}
> Moving to 4.4.3 resolves the issue. PR builds are able to finish normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4373) Upgrade Karaf to 4.4.3
[
https://issues.apache.org/jira/browse/ARTEMIS-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4373:
Affects Version/s: 2.30.0
> Upgrade Karaf to 4.4.3
> --
>
> Key: ARTEMIS-4373
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4373
> Project: ActiveMQ Artemis
> Issue Type: Dependency upgrade
>Affects Versions: 2.30.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PR builds on JDK 20 recently started failing with:
> {noformat}
> Error: Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project
> artemis-features: Execution verify of goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required
> class was missing while executing
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify:
> org/apache/karaf/features/internal/download/DownloadManager{noformat}
> Moving to 4.4.3 resolves the issue. PR builds are able to finish normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4373) Upgrade Karaf to 4.4.3
[
https://issues.apache.org/jira/browse/ARTEMIS-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4373.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> Upgrade Karaf to 4.4.3
> --
>
> Key: ARTEMIS-4373
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4373
> Project: ActiveMQ Artemis
> Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PR builds on JDK 20 recently started failing with:
> {noformat}
> Error: Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify (verify) on project
> artemis-features: Execution verify of goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify failed: A required
> class was missing while executing
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.3:verify:
> org/apache/karaf/features/internal/download/DownloadManager{noformat}
> Moving to 4.4.3 resolves the issue. PR builds are able to finish normally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4369) add clarifying note to docs around transport options for broker-connections
[ https://issues.apache.org/jira/browse/ARTEMIS-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4369. - Resolution: Fixed > add clarifying note to docs around transport options for broker-connections > --- > > Key: ARTEMIS-4369 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4369 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: 2.31.0 > > > Add clarifying note to the docs around URI transport options for > broker-connections, e.g enabling and configuration TLS, being the same as for > other connection URIs. Mention there is an example showing it in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4369) add clarifying note to docs around transport options for broker-connections
Robbie Gemmell created ARTEMIS-4369: --- Summary: add clarifying note to docs around transport options for broker-connections Key: ARTEMIS-4369 URL: https://issues.apache.org/jira/browse/ARTEMIS-4369 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.31.0 Add clarifying note to the docs around URI transport options for broker-connections, e.g enabling and configuration TLS, being the same as for other connection URIs. Mention there is an example showing it in use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
