[jira] [Created] (ARTEMIS-3347) update commons-io
Robbie Gemmell created ARTEMIS-3347: --- Summary: update commons-io Key: ARTEMIS-3347 URL: https://issues.apache.org/jira/browse/ARTEMIS-3347 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Broker, Tests, Web Console Reporter: Robbie Gemmell The codebase uses various versions of commons-io which are susceptible to a path traversal CVE [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], which affects < 2.7.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3347) update commons-io
[ https://issues.apache.org/jira/browse/ARTEMIS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363528#comment-17363528 ] Robbie Gemmell commented on ARTEMIS-3347: - An initial update was made in the following commit, but it misses some explicitly set versions, and the web console pulling in an older version via hawtio, so the general issue still remains: [https://github.com/apache/activemq-artemis/commit/73bcc78beb58ad5a30a46c051955dbc9f17fb530] There was also a newer commons-io release since then. > update commons-io > - > > Key: ARTEMIS-3347 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3347 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Broker, Tests, Web Console >Reporter: Robbie Gemmell >Priority: Major > > The codebase uses various versions of commons-io which are susceptible to a > path traversal CVE > [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], > which affects < 2.7.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3347) update commons-io
[ https://issues.apache.org/jira/browse/ARTEMIS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3347: Fix Version/s: 2.18.0 > update commons-io > - > > Key: ARTEMIS-3347 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3347 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Broker, Tests, Web Console >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > The codebase uses various versions of commons-io which are susceptible to a > path traversal CVE > [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], > which affects < 2.7.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3348) update hawtio
Robbie Gemmell created ARTEMIS-3348: --- Summary: update hawtio Key: ARTEMIS-3348 URL: https://issues.apache.org/jira/browse/ARTEMIS-3348 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Web Console Affects Versions: 2.17.0 Reporter: Robbie Gemmell Fix For: 2.18.0 Update hawtio to 2.13.4. The existing 2.13.2 version used by the console uses an older version of commons-io susceptible to a path traversal CVE [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], which affects < 2.7.0. The only differences from 2.13.2 were dependency upgrades for commons-io and jackson to get various CVE fixes such as the above: https://github.com/hawtio/hawtio/compare/hawtio-2.13.2...hawtio-2.13.4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3349) Documentation Task for Artemis Transports
[ https://issues.apache.org/jira/browse/ARTEMIS-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363611#comment-17363611 ] Robbie Gemmell commented on ARTEMIS-3349: - It would help if you could point to which specific doc you followed to the letter, so someone could actually check it for issues. The broker uses Netty for the NIO transport as well, and the lib dir includes netty-all which bundles all of Netty including those modules you mentioned, so that shouldnt really have made a difference, making it doubly odd. > Documentation Task for Artemis Transports > - > > Key: ARTEMIS-3349 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3349 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker, Configuration >Affects Versions: 2.17.0 > Environment: Red Hat Enterprise Linux Server release 7.9 > Linux.10.0-1160.11.1.el7.x86_64 #1 SMP Mon Nov 30 13:05:31 EST 2020 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Tony Dunbar >Priority: Minor > > I am fairly new to Apache Artemis, and attempted the install to test a stomp > client. I am not sure if this is a initial configuration issue or a > documentation issue. I followed the install instructions, to the letter, > from the Artemis documentation. The initial configuration of the > etc/broker.xml during the installation will fail if the netty dependency is > not satisfied upon server startup. I attempted the installation on a newly > created VM. The only way I could get the server to accept messages was to > change the useEpoll setting in the etc/broker.xml from true to false. This > allows the initial installation to use the built in NIO transport. After > turning on DEBUG logging and a lot of research, I was eventually able to > download and copy the dependent netty jars to the /lib > directory. Then changed the useEpoll setting in the etc/broker.xml from > false to true. Restarted the artemis service and now the netty transport was > being used successfully. The dependent netty jars are: > netty-transport-4.x.Final.jar > netty-buffer-4.x.Final.jar > netty-common-4.x.Final.jar > netty-resolver-4.x.Final.jar > In my humble opinion, your installation of Artemis assumes the host machine > will already have Netty transport installed, perhaps from some other > application install. You should either package the netty dependencies in the > /lib directory or default the useEpoll settings to false. > Thanks > Tony -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3296) enable building on Java 16
[ https://issues.apache.org/jira/browse/ARTEMIS-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3296. - Fix Version/s: 2.18.0 Resolution: Fixed > enable building on Java 16 > -- > > Key: ARTEMIS-3296 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3296 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > The maven build currently fails immediately if using Java 16+, first due to > the enforcer plugin not handling the new impl, then various other issues > thereafter. > Many of the build plugins are stale, some being very very old, either from > using the old v18 apache parent or from being explicitly defined in the > artemis root pom. A general refresh should be done to update to more recent > plugin versions, via the current v23 apache parent or otherwise if needing > newer yet versions, and dependencies updated as well as needed to get the > build going on Java 16 (and 17EA). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3348) update hawtio
[ https://issues.apache.org/jira/browse/ARTEMIS-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3348. - Resolution: Fixed > update hawtio > - > > Key: ARTEMIS-3348 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3348 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Web Console >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > Update hawtio to 2.13.4. > > The existing 2.13.2 version used by the console uses an older version of > commons-io susceptible to a path traversal CVE > [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], > which affects < 2.7.0. > > The only differences from 2.13.2 were dependency upgrades for commons-io and > jackson to get various CVE fixes such as the above: > https://github.com/hawtio/hawtio/compare/hawtio-2.13.2...hawtio-2.13.4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3347) update commons-io
[ https://issues.apache.org/jira/browse/ARTEMIS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3347. - Resolution: Fixed > update commons-io > - > > Key: ARTEMIS-3347 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3347 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Broker, Tests, Web Console >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The codebase uses various versions of commons-io which are susceptible to a > path traversal CVE > [https://nvd.nist.gov/vuln/detail/CVE-2021-29425|https://nvd.nist.gov/vuln/detail/CVE-2021-29425.], > which affects < 2.7.0 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3241) binary archive LICENSE file contains improper (and possibly stale) entries for management console deps
[ https://issues.apache.org/jira/browse/ARTEMIS-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3241. - Resolution: Fixed > binary archive LICENSE file contains improper (and possibly stale) entries > for management console deps > -- > > Key: ARTEMIS-3241 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3241 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Domenico Francesco Bruscino >Priority: Blocker > Fix For: 2.18.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > The licence file shipped with the binary distribution contains a lot of > improper, and possibly stale (see later), entries relating to the management > console deps: > https://github.com/apache/activemq-artemis/blob/2.17.0/artemis-distribution/src/main/resources/licenses/bin/LICENSE#L256-L435 > These entries added mostly link to a file in an external repository, on its > master branch. This applicable licences should actually be in the > distribution itself (either directly in LICENCE, or in another file > referenced from it), links arent sufficient because their contents can change > over time (e.g licence and/or version changes) or even go away entirely or > just be broken (e.g branch changes) and so may not actually reflect the > needed detail or the state that existed when the dependency was used and the > LICENCE file entry added. > Further, these entries could also be somewhat stale now, because they were > added in ARTEMIS-1270 back in 2017 but the console has been overhauled > recently in ARTEMIS-2838. In addition to being updated to actually ship the > licence, the entries should be verified as still applying, and that there > aren't any new ones needed from the console update. > (Noticed during discussion of LICENSE changes on > https://github.com/apache/activemq-artemis/pull/3527 / ARTEMIS-3221) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3352) misc pom cleanups
Robbie Gemmell created ARTEMIS-3352: --- Summary: misc pom cleanups Key: ARTEMIS-3352 URL: https://issues.apache.org/jira/browse/ARTEMIS-3352 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.17.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.18.0 There is various cruft in the build that could be removed or tidied up, raising JIRA to group various little improvements. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3352) misc pom cleanups
[ https://issues.apache.org/jira/browse/ARTEMIS-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3352. - Resolution: Fixed > misc pom cleanups > - > > Key: ARTEMIS-3352 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3352 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.18.0 > > > There is various cruft in the build that could be removed or tidied up, > raising JIRA to group various little improvements. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3373) Update org.apache.activemq.artemis.utils.collections to be consistent on Types
[ https://issues.apache.org/jira/browse/ARTEMIS-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3373: Description: Some template interfaces under org.apache.activemq.artemis.utils.collections are using (for Type I assume) and some are using (for element I assume). during development of ARTEMIS-3243 I came across this and I wanted to make it consistent. was: Some template interfaces under org.apache.activemq.artemis.utils.collections are using (for Type I assume) and some are using (for element I assume). during development of ARTEMIS-3243 I came across this and I wanted to make it consistent. Updated description to make them inconsistent :) > Update org.apache.activemq.artemis.utils.collections to be consistent on Types > -- > > Key: ARTEMIS-3373 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3373 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.18.0 > > > Some template interfaces under org.apache.activemq.artemis.utils.collections > are using (for Type I assume) and some are using (for element I > assume). > > during development of ARTEMIS-3243 I came across this and I wanted to make it > consistent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3357) Setting multicast: prefix explicitely when reconnecting a durable AMQP client causes the queue to be renewed and all pending messages lost
[ https://issues.apache.org/jira/browse/ARTEMIS-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376482#comment-17376482 ] Robbie Gemmell commented on ARTEMIS-3357: - One thing you can do is add a "queue" or "topic" capability to a consumer links 'source' terminus. The broker looks for these, its what e.g the Qpid JMS client does to provide a hint to brokers that might want to auto create things. E.g see example of that at: https://github.com/amqphub/equipage/tree/main/qpid-proton-python/auto-create > Setting multicast: prefix explicitely when reconnecting a durable AMQP client > causes the queue to be renewed and all pending messages lost > -- > > Key: ARTEMIS-3357 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3357 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.17.0 >Reporter: NS-SlaFleur >Priority: Critical > > Hello! > > This issue was created after a discussion on the > [us...@activemq.apache.org|mailto:us...@activemq.apache.org] mailing list. > Subject: 'Understanding of Artemis multicastPrefix in AMQP address prevents > the transfer of historical and pending messages of queue' in June 2021. > [http://mail-archives.apache.org/mod_mbox/activemq-users/202106.mbox/%3Cbf67a06968df4b04a141edf382c5fc81%40NWMLMBX1004.ns.wpol.nl%3E] > > Currently you may tell Artemis to auto-create a durable queue with AMQP by > setting the source terminus to a durable value. This allows pending messages > on the queue to be retrieved by the receiver on a reconnect. However, if you > set the multicast: prefix explicitely and reconnect, the queue will be > replaced by a queue with a new ID and all pending messages are lost. > > I have reproduced this issue both with the Artemis client binary and with an > AMQP python proton client. > > Steps based on Artemis binary which shows behavior is limited to setting the > multicast prefix explicitely: > What I will show are 2 points: 1) The ALL command does not renew/overwrite > the existing, durable subscription queue. Pending messages are received. and > 2) The NEW does renew/overwrite the existing, durable subscription queue. > Pending messages are lost. > Both situations appear to not influence each other as the order in which the > 2 tests are tried do not matter. > > Startup every test: > # Configure the 'someUser' user with the amq role and password 'somePassword' > # Start Artemis 2.17.0 with the broker.xml from the link. > # Change directory to the Artemis binary. > # Login and open the management console at > [http://localhost:8161/console/artemis/artemisQueues?nid=root-org.apache.activemq.artemis-ARTEMIS] > in a browser (the Queues page) 4. Run this command in a separate terminal: > ./artemis producer --user someUser --password somePassword --url > amqp://localhost:5672 --sleep 1000 --protocol amqp --destination > topic://foobar --verbose > > Cleanup every test: > # Close terminals > # Close management console. > # Quit Artemis. > # Remove persistent files e.g. docker container & volume. > > Test ALL: > # Run: ./artemis consumer --durable --protocol amqp --user someUser > --password somePassword --clientID artemisconsoleALL --destination > topic://foobar --url amqp://localhost:5672 --verbose 6. Note: > - Messages are now being received in the terminal. > - In the management console click reset and note that a queue is created > with the name 'artemisconsoleALL.Consumer foobar, thread=0'. > - The ID of the queue. > - The queue is multicast. > - The queue is durable. > # Quit the command with CTRL+C and wait a couple of seconds. > # Note that the messages on the queue is increasing in the management > console. > # Run the command again to connect the receiver. > # Note that ALL pending messages are received. Note that the queue id in the > management console did NOT change. Note that the queue in the management > console now has 0 pending messages. > > Test NEW: > # Run: ./artemis consumer --durable --protocol amqp --user someUser > --password somePassword --clientID artemisconsoleNEW --destination > topic://multicast:foobar --url amqp://localhost:5672 --verbose 6. Note: > - Messages are now being received in the terminal. > - In the management console click reset and note that a queue is created > with the name 'artemisconsoleNEW.Consumer multicast:foobar, thread=0'. > - The ID of the queue. > - The queue is multicast. > - The queue is durable. > # Quit the command with CTRL+C and wait a couple of seconds. > # Note that the messages on the queue is increasing in the management > console. > # Run the command again to connect the
[jira] [Commented] (ARTEMIS-3185) Various TLS tests fail on newer JDKs/environments
[
https://issues.apache.org/jira/browse/ARTEMIS-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386125#comment-17386125
]
Robbie Gemmell commented on ARTEMIS-3185:
-
Its fairly typical for such things to live beside the test using them or in the
src/test/resources of the module the tests exist, the latter in particular if
they are general files that most tests would only need to use an identical set
for. I would guess the folks that used these 'mqtt crl' files for other tests
in the integration tests module did so because of the latter and especially
given the files particularly generic naming. I didnt add most of the uses of
them but certainly could have some of them, as its really the obvious usage to
go for. Most of these tests just need a very simple server keystore and a trust
store with the CA cert that signed it (actually I've come to realise none of
the other stores use a CA cert, besides those 'mqtt crl' ones, I would also
change that to make the tests better/more-representative and also simplify the
number of stores needed).
I dont think that it really makes more sense for the instructions of basic
keystores+truststore to be embedded across different tests deep within the
source tree, and need to be copied out of their javadoc and edited in order to
run, and then for the resulting stores files to be created all alongside each
other but in an entirely different maven module from those instructions (files
under tests/unit-tests, instructions inside tests within
tests/integration-tests).
Its so much simpler to update the keystore/truststore resources if they sit
next to instructions that can simply be executed as a script to regenerate
them. Theres no confusion about which commands were run or from where and
updating the files takes a instant to run/source the existing script (modifying
the script first if needed), less time than even finding and copying ones
embedded in different tests elsewhere. Looking for all changes to the files and
the commands that created them? Simple check of the diff of that sole location.
> Various TLS tests fail on newer JDKs/environments
> -
>
> Key: ARTEMIS-3185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3185
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.17.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> Various broker integration tests fail after I updated to Fedora 33, seemingly
> on all JDK versions but certainly with 8u275 and above, with the failing
> tests all being TLS related. For example, AMQPConnectSaslTest,
> JMSSaslExternalTest, JMSSaslExternalLDAPTest failed, though there are others.
> Specifically, the related keystore for those tests looks to be keystore1.jks
> under tests/integration-tests/src/test/resources (though possibly other files
> in there and related tests could be affected or need updated also). The key
> contained uses SHA1withRSA for the signature, which keytool notes is disabled
> and so that is presumably the problem:
> {noformat}
> $ keytool -keystore keystore1.jks -storepass changeit -list -v
> ...snipped...
> Signature algorithm name: SHA1withRSA (disabled)
> ...snipped...
> uses the SHA1withRSA signature algorithm which is considered a
> security risk and is disabled.
> {noformat}
> I'm not clear how the file was generated and dont see the CA key used to sign
> it and which matches up to the truststore.jks file (it uses SHA256withRSA sig
> and so should be fine if the key were updated in isolation). If someone who
> knows the process used could update the key that would be great.
> A suggestion I would make is to create a script that creates the files, both
> so it can be seen later what was done, and more easily repeated and/or
> updated when needed. E.g for example we do this with the [Qpid JMS tests
> resources|https://github.com/apache/qpid-jms/blob/0.57.0/qpid-jms-client/src/test/resources/README.txt],
> which I adapted for creating the ['broker-connections' TLS
> example|https://github.com/apache/activemq-artemis/blob/master/examples/features/broker-connection/amqp-sending-overssl/store-generation.txt]
> resources when I was updating that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3185) Various TLS tests fail on newer JDKs/environments
[
https://issues.apache.org/jira/browse/ARTEMIS-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3185:
Description:
Various broker integration tests fail after I updated to Fedora 33, seemingly
on all JDK versions but certainly with 8u275 and above, with the failing tests
all being TLS related. For example, AMQPConnectSaslTest, JMSSaslExternalTest,
JMSSaslExternalLDAPTest failed, though there are others.
Specifically, the related keystore for those tests looks to be keystore1.jks
under tests/integration-tests/src/test/resources (though possibly other files
in there and related tests could be affected or need updated also). The key
contained uses SHA1withRSA for the signature, which keytool notes is disabled
and so that is presumably the problem:
{noformat}
$ keytool -keystore keystore1.jks -storepass changeit -list -v
...snipped...
Signature algorithm name: SHA1withRSA (disabled)
...snipped...
uses the SHA1withRSA signature algorithm which is considered a
security risk and is disabled.
{noformat}
I'm not clear how the file was generated and dont see the CA key used to sign
it and which matches up to the truststore.jks file (it uses SHA256withRSA sig
and so should be fine if the key were updated in isolation). If someone who
knows the process used could update the key that would be great.
A suggestion I would make is to create a script that creates the files, both so
it can be seen later what was done, and more easily repeated and/or updated
when needed. E.g for example we do this with the [Qpid JMS tests
resources|https://github.com/apache/qpid-jms/blob/main/qpid-jms-client/src/test/resources/README.txt],
which I adapted for creating the ['broker-connections' TLS
example|https://github.com/apache/activemq-artemis/blob/master/examples/features/broker-connection/amqp-sending-overssl/store-generation.txt]
resources when I was updating that.
was:
Various broker integration tests fail after I updated to Fedora 33, seemingly
on all JDK versions but certainly with 8u275 and above, with the failing tests
all being TLS related. For example, AMQPConnectSaslTest, JMSSaslExternalTest,
JMSSaslExternalLDAPTest failed, though there are others.
Specifically, the related keystore for those tests looks to be keystore1.jks
under tests/integration-tests/src/test/resources (though possibly other files
in there and related tests could be affected or need updated also). The key
contained uses SHA1withRSA for the signature, which keytool notes is disabled
and so that is presumably the problem:
{noformat}
$ keytool -keystore keystore1.jks -storepass changeit -list -v
...snipped...
Signature algorithm name: SHA1withRSA (disabled)
...snipped...
uses the SHA1withRSA signature algorithm which is considered a
security risk and is disabled.
{noformat}
I'm not clear how the file was generated and dont see the CA key used to sign
it and which matches up to the truststore.jks file (it uses SHA256withRSA sig
and so should be fine if the key were updated in isolation). If someone who
knows the process used could update the key that would be great.
A suggestion I would make is to create a script that creates the files, both so
it can be seen later what was done, and more easily repeated and/or updated
when needed. E.g for example we do this with the [Qpid JMS tests
resources|https://github.com/apache/qpid-jms/blob/0.57.0/qpid-jms-client/src/test/resources/README.txt],
which I adapted for creating the ['broker-connections' TLS
example|https://github.com/apache/activemq-artemis/blob/master/examples/features/broker-connection/amqp-sending-overssl/store-generation.txt]
resources when I was updating that.
> Various TLS tests fail on newer JDKs/environments
> -
>
> Key: ARTEMIS-3185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3185
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.17.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> Various broker integration tests fail after I updated to Fedora 33, seemingly
> on all JDK versions but certainly with 8u275 and above, with the failing
> tests all being TLS related. For example, AMQPConnectSaslTest,
> JMSSaslExternalTest, JMSSaslExternalLDAPTest failed, though there are others.
> Specifically, the related keystore for those tests looks to be keystore1.jks
> under tests/integration-tests/src/test/resources (though possibly other files
> in there and related tests could be affected or need updated also). The key
> contained uses SHA1withRSA for the signature, which keytool notes is disabled
> and so that is presumably the problem:
> {noformat}
> $ keytool -keystore keystore1.jks -storepass changeit -list -v
> ...snipped...
> Signature algorithm name: SHA1withRSA (disa
[jira] [Updated] (ARTEMIS-3304) replace Long/Double/etc constructor usage marked deprecated for-removal
[ https://issues.apache.org/jira/browse/ARTEMIS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3304: Description: The Long/Double/etc constructors were deprecated in Java 9. Some of the selector code and lots of tests are still using these. The methods remain in place currently, but the deprecation has been raised to for-removal status in Java 16, meaning they are likely to actually go away in future. The valueOf methods should be used instead. (was: The Long/Double/etc constructors were deprecated in Java 9. Some of the selector code is still using these. The methods remain in place currently, but the deprecation has been raised to for-removal status in Java 16, meaning they are likely to actually go away in future. The valueOf methods should be used instead.) Summary: replace Long/Double/etc constructor usage marked deprecated for-removal (was: replace Long/Double constructor usage marked deprecated for-removal) > replace Long/Double/etc constructor usage marked deprecated for-removal > --- > > Key: ARTEMIS-3304 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3304 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > The Long/Double/etc constructors were deprecated in Java 9. Some of the > selector code and lots of tests are still using these. The methods remain in > place currently, but the deprecation has been raised to for-removal status in > Java 16, meaning they are likely to actually go away in future. The valueOf > methods should be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3304) replace Long/Double constructor usage marked deprecated for-removal
[ https://issues.apache.org/jira/browse/ARTEMIS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-3304: - > replace Long/Double constructor usage marked deprecated for-removal > --- > > Key: ARTEMIS-3304 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3304 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > The Long/Double/etc constructors were deprecated in Java 9. Some of the > selector code is still using these. The methods remain in place currently, > but the deprecation has been raised to for-removal status in Java 16, meaning > they are likely to actually go away in future. The valueOf methods should be > used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3302) various use of deprecated-for-removal javax.security.cert.X509Certificate
[
https://issues.apache.org/jira/browse/ARTEMIS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388085#comment-17388085
]
Robbie Gemmell commented on ARTEMIS-3302:
-
Related instances needing updated:
{quote}[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[29,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[29,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[29,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[29,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[30,7]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java:[35,60]
getPeerCertificateChain() in javax.net.ssl.SSLSession has been deprecated and
marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java:[34,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java:[34,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java:[34,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java:[34,18]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java:[35,7]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java:[596,10]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/ExternalCertificateLoginModule.java:[69,7]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[46,12]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[46,12]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[46,12]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[46,12]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[157,57]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for removal
[WARNING]
/path.to/activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java:[157,57]
javax.security.cert.X509Certificate in javax.security.cert has been deprecated
and marked for re
[jira] [Commented] (ARTEMIS-3302) various use of deprecated-for-removal javax.security.cert.X509Certificate
[
https://issues.apache.org/jira/browse/ARTEMIS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388088#comment-17388088
]
Robbie Gemmell commented on ARTEMIS-3302:
-
The above instances belong to these 16 files:
{noformat}
activemq-artemis/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/CertificateUtil.java
activemq-artemis/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/security/impl/SecurityStoreImpl.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager2.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateCallback.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/CertificateLoginModule.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/ExternalCertificateLoginModule.java
activemq-artemis/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/TextFileCertificateLoginModule.java
activemq-artemis/artemis-server/src/test/java/org/apache/activemq/artemis/core/security/jaas/StubCertificateLoginModule.java
activemq-artemis/artemis-server/src/test/java/org/apache/activemq/artemis/core/security/jaas/StubX509Certificate.java
activemq-artemis/artemis-server/src/test/java/org/apache/activemq/artemis/core/security/jaas/TextFileCertificateLoginModuleTest.java
activemq-artemis/tests/activemq5-unit-tests/src/test/java/org/apache/activemq/transport/tcp/SslBrokerServiceTest.java
activemq-artemis/tests/activemq5-unit-tests/src/test/java/org/apache/activemq/transport/tcp/StubSSLSession.java
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/security/SecurityTest.java
activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/ssl/CoreClientOverTwoWaySSLTest.java
{noformat}
> various use of deprecated-for-removal javax.security.cert.X509Certificate
> -
>
> Key: ARTEMIS-3302
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3302
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.17.0
>Reporter: Robbie Gemmell
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The codebase is using javax.security.cert.X509Certificate in various places.
> This was noted superceded by the java.security.cert replacement since ~Java
> 1.4, and marked deprecated in Java 9 along with the entire
> javax.security.cert package. The deprecation was raised to for-removal status
> in Java 13 [1].
> Building using Java 16 [2] without using the -release flag (which doesnt
> actually work for Artemis due to API usages that -release doesnt permit)
> means the build uses the Java 16 signatures when compiling regardless what
> the -target version is, which has the side effect of helpfully pointing out a
> lot of deprecated-for-removal APIs that the codebase is still using.
> [1] https://bugs.openjdk.java.net/browse/JDK-8160247
> [2]
> https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3304) replace Long/Double/etc constructor usage marked deprecated for-removal
[ https://issues.apache.org/jira/browse/ARTEMIS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3304. - Resolution: Fixed > replace Long/Double/etc constructor usage marked deprecated for-removal > --- > > Key: ARTEMIS-3304 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3304 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > The Long/Double/etc constructors were deprecated in Java 9. Some of the > selector code and lots of tests are still using these. The methods remain in > place currently, but the deprecation has been raised to for-removal status in > Java 16, meaning they are likely to actually go away in future. The valueOf > methods should be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3357) Setting multicast: prefix explicitely when reconnecting a durable AMQP client causes the queue to be renewed and all pending messages lost
[ https://issues.apache.org/jira/browse/ARTEMIS-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388873#comment-17388873 ] Robbie Gemmell commented on ARTEMIS-3357: - You're welcome. > Setting multicast: prefix explicitely when reconnecting a durable AMQP client > causes the queue to be renewed and all pending messages lost > -- > > Key: ARTEMIS-3357 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3357 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.17.0 >Reporter: NS-SlaFleur >Priority: Critical > > Hello! > > This issue was created after a discussion on the > [us...@activemq.apache.org|mailto:us...@activemq.apache.org] mailing list. > Subject: 'Understanding of Artemis multicastPrefix in AMQP address prevents > the transfer of historical and pending messages of queue' in June 2021. > [http://mail-archives.apache.org/mod_mbox/activemq-users/202106.mbox/%3Cbf67a06968df4b04a141edf382c5fc81%40NWMLMBX1004.ns.wpol.nl%3E] > > Currently you may tell Artemis to auto-create a durable queue with AMQP by > setting the source terminus to a durable value. This allows pending messages > on the queue to be retrieved by the receiver on a reconnect. However, if you > set the multicast: prefix explicitely and reconnect, the queue will be > replaced by a queue with a new ID and all pending messages are lost. > > I have reproduced this issue both with the Artemis client binary and with an > AMQP python proton client. > > Steps based on Artemis binary which shows behavior is limited to setting the > multicast prefix explicitely: > What I will show are 2 points: 1) The ALL command does not renew/overwrite > the existing, durable subscription queue. Pending messages are received. and > 2) The NEW does renew/overwrite the existing, durable subscription queue. > Pending messages are lost. > Both situations appear to not influence each other as the order in which the > 2 tests are tried do not matter. > > Startup every test: > # Configure the 'someUser' user with the amq role and password 'somePassword' > # Start Artemis 2.17.0 with the broker.xml from the link. > # Change directory to the Artemis binary. > # Login and open the management console at > [http://localhost:8161/console/artemis/artemisQueues?nid=root-org.apache.activemq.artemis-ARTEMIS] > in a browser (the Queues page) 4. Run this command in a separate terminal: > ./artemis producer --user someUser --password somePassword --url > amqp://localhost:5672 --sleep 1000 --protocol amqp --destination > topic://foobar --verbose > > Cleanup every test: > # Close terminals > # Close management console. > # Quit Artemis. > # Remove persistent files e.g. docker container & volume. > > Test ALL: > # Run: ./artemis consumer --durable --protocol amqp --user someUser > --password somePassword --clientID artemisconsoleALL --destination > topic://foobar --url amqp://localhost:5672 --verbose 6. Note: > - Messages are now being received in the terminal. > - In the management console click reset and note that a queue is created > with the name 'artemisconsoleALL.Consumer foobar, thread=0'. > - The ID of the queue. > - The queue is multicast. > - The queue is durable. > # Quit the command with CTRL+C and wait a couple of seconds. > # Note that the messages on the queue is increasing in the management > console. > # Run the command again to connect the receiver. > # Note that ALL pending messages are received. Note that the queue id in the > management console did NOT change. Note that the queue in the management > console now has 0 pending messages. > > Test NEW: > # Run: ./artemis consumer --durable --protocol amqp --user someUser > --password somePassword --clientID artemisconsoleNEW --destination > topic://multicast:foobar --url amqp://localhost:5672 --verbose 6. Note: > - Messages are now being received in the terminal. > - In the management console click reset and note that a queue is created > with the name 'artemisconsoleNEW.Consumer multicast:foobar, thread=0'. > - The ID of the queue. > - The queue is multicast. > - The queue is durable. > # Quit the command with CTRL+C and wait a couple of seconds. > # Note that the messages on the queue is increasing in the management > console. > # Run the command again to connect the receiver. > # Note that NO pending messages are received. Note that the queue id in the > management console did change. Note that the queue in the management console > now has 0 pending messages. > > Conclusion: For 2 independent durable subscriptions adding the multicast: > prefix will remove the existing durable sub
[jira] [Created] (ARTEMIS-3407) update pax-exam to 4.13.4 and karaf to 4.3.1, get related tests to work on Java 11
Robbie Gemmell created ARTEMIS-3407: --- Summary: update pax-exam to 4.13.4 and karaf to 4.3.1, get related tests to work on Java 11 Key: ARTEMIS-3407 URL: https://issues.apache.org/jira/browse/ARTEMIS-3407 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Affects Versions: 2.17.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.18.0 There are various karaf client integration tests, under tests/karaf-client-integration-tests, which do not currently work when running the build+tests on Java 11. They sit around waiting for a while, taking 15+mins to fail. Upgrading pax-exam to 4.13.4 and karaf to 4.3.1 gets the tests running and passing (in ~1min). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3407) update pax-exam to 4.13.4 and karaf to 4.3.1, get related tests to work on Java 11
[ https://issues.apache.org/jira/browse/ARTEMIS-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3407. - Resolution: Fixed > update pax-exam to 4.13.4 and karaf to 4.3.1, get related tests to work on > Java 11 > -- > > Key: ARTEMIS-3407 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3407 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There are various karaf client integration tests, under > tests/karaf-client-integration-tests, which do not currently work when > running the build+tests on Java 11. They sit around waiting for a while, > taking 15+mins to fail. > Upgrading pax-exam to 4.13.4 and karaf to 4.3.1 gets the tests running and > passing (in ~1min). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3409) DNSSwitchTest skips on Java 8 but fails on Java 11+ if preconditions not satisfied
Robbie Gemmell created ARTEMIS-3409: --- Summary: DNSSwitchTest skips on Java 8 but fails on Java 11+ if preconditions not satisfied Key: ARTEMIS-3409 URL: https://issues.apache.org/jira/browse/ARTEMIS-3409 Project: ActiveMQ Artemis Issue Type: Test Components: Tests Affects Versions: 2.17.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.18.0 The DNSSwitchTest smoke test does slightly different things to operate on Java 8 and Java 11+, and as a result makes different precondition checks for the two cases. These can behave quite differently, such that when it cant run on Java 8 it typically skips, but when it cant run on Java 11 it typically outright fails. It should be consistent and skip when any preconditions for running cant be satisfied. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3409) DNSSwitchTest skips on Java 8 but fails on Java 11+ if preconditions not satisfied
[ https://issues.apache.org/jira/browse/ARTEMIS-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3409. - Resolution: Fixed > DNSSwitchTest skips on Java 8 but fails on Java 11+ if preconditions not > satisfied > -- > > Key: ARTEMIS-3409 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3409 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The DNSSwitchTest smoke test does slightly different things to operate on > Java 8 and Java 11+, and as a result makes different precondition checks for > the two cases. These can behave quite differently, such that when it cant run > on Java 8 it typically skips, but when it cant run on Java 11 it typically > outright fails. > It should be consistent and skip when any preconditions for running cant be > satisfied. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3302) various use of deprecated-for-removal javax.security.cert.X509Certificate
[ https://issues.apache.org/jira/browse/ARTEMIS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3302: Description: The codebase is using javax.security.cert.X509Certificate in various places. This was noted superceded by the java.security.cert replacement since ~Java 1.4, and marked deprecated in Java 9 along with the entire javax.security.cert package. The deprecation was raised to for-removal status in Java 13 [1]. Building using Java 16 [2] without using the -release flag (which doesnt actually work for Artemis due to API usages that -release doesnt permit) means the build uses the Java 16 signatures when compiling regardless what the -target version is, which has the side effect of helpfully pointing out a lot of deprecated-for-removal APIs that the codebase is still using. They have actually removed the impl for some of the deprecated bits in Java 15 already [3], e.g changing them to default interface methods that throw UnsupportedOperationException, meaning no current Artemis release works on Java 15+ if using SSL/TLS and calling those methods. [1] [https://bugs.openjdk.java.net/browse/JDK-8160247] [2] [https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true] [3] [https://bugs.openjdk.java.net/browse/JDK-8241047] was: The codebase is using javax.security.cert.X509Certificate in various places. This was noted superceded by the java.security.cert replacement since ~Java 1.4, and marked deprecated in Java 9 along with the entire javax.security.cert package. The deprecation was raised to for-removal status in Java 13 [1]. Building using Java 16 [2] without using the -release flag (which doesnt actually work for Artemis due to API usages that -release doesnt permit) means the build uses the Java 16 signatures when compiling regardless what the -target version is, which has the side effect of helpfully pointing out a lot of deprecated-for-removal APIs that the codebase is still using. [1] https://bugs.openjdk.java.net/browse/JDK-8160247 [2] https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true > various use of deprecated-for-removal javax.security.cert.X509Certificate > - > > Key: ARTEMIS-3302 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3302 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Priority: Critical > Time Spent: 1h > Remaining Estimate: 0h > > The codebase is using javax.security.cert.X509Certificate in various places. > This was noted superceded by the java.security.cert replacement since ~Java > 1.4, and marked deprecated in Java 9 along with the entire > javax.security.cert package. The deprecation was raised to for-removal status > in Java 13 [1]. > Building using Java 16 [2] without using the -release flag (which doesnt > actually work for Artemis due to API usages that -release doesnt permit) > means the build uses the Java 16 signatures when compiling regardless what > the -target version is, which has the side effect of helpfully pointing out a > lot of deprecated-for-removal APIs that the codebase is still using. > They have actually removed the impl for some of the deprecated bits in Java > 15 already [3], e.g changing them to default interface methods that throw > UnsupportedOperationException, meaning no current Artemis release works on > Java 15+ if using SSL/TLS and calling those methods. > [1] [https://bugs.openjdk.java.net/browse/JDK-8160247] > [2] > [https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true] > [3] [https://bugs.openjdk.java.net/browse/JDK-8241047] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3302) various use of deprecated-for-removal javax.security.cert.X509Certificate
[ https://issues.apache.org/jira/browse/ARTEMIS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-3302: --- Assignee: Justin Bertram > various use of deprecated-for-removal javax.security.cert.X509Certificate > - > > Key: ARTEMIS-3302 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3302 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Justin Bertram >Priority: Critical > Time Spent: 1h > Remaining Estimate: 0h > > The codebase is using javax.security.cert.X509Certificate in various places. > This was noted superceded by the java.security.cert replacement since ~Java > 1.4, and marked deprecated in Java 9 along with the entire > javax.security.cert package. The deprecation was raised to for-removal status > in Java 13 [1]. > Building using Java 16 [2] without using the -release flag (which doesnt > actually work for Artemis due to API usages that -release doesnt permit) > means the build uses the Java 16 signatures when compiling regardless what > the -target version is, which has the side effect of helpfully pointing out a > lot of deprecated-for-removal APIs that the codebase is still using. > They have actually removed the impl for some of the deprecated bits in Java > 15 already [3], e.g changing them to default interface methods that throw > UnsupportedOperationException, meaning no current Artemis release works on > Java 15+ if using SSL/TLS and calling those methods. > [1] [https://bugs.openjdk.java.net/browse/JDK-8160247] > [2] > [https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true] > [3] [https://bugs.openjdk.java.net/browse/JDK-8241047] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3302) various use of deprecated-for-removal javax.security.cert.X509Certificate
[ https://issues.apache.org/jira/browse/ARTEMIS-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3302. - Fix Version/s: 2.18.0 Resolution: Fixed > various use of deprecated-for-removal javax.security.cert.X509Certificate > - > > Key: ARTEMIS-3302 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3302 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Robbie Gemmell >Assignee: Justin Bertram >Priority: Critical > Fix For: 2.18.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The codebase is using javax.security.cert.X509Certificate in various places. > This was noted superceded by the java.security.cert replacement since ~Java > 1.4, and marked deprecated in Java 9 along with the entire > javax.security.cert package. The deprecation was raised to for-removal status > in Java 13 [1]. > Building using Java 16 [2] without using the -release flag (which doesnt > actually work for Artemis due to API usages that -release doesnt permit) > means the build uses the Java 16 signatures when compiling regardless what > the -target version is, which has the side effect of helpfully pointing out a > lot of deprecated-for-removal APIs that the codebase is still using. > They have actually removed the impl for some of the deprecated bits in Java > 15 already [3], e.g changing them to default interface methods that throw > UnsupportedOperationException, meaning no current Artemis release works on > Java 15+ if using SSL/TLS and calling those methods. > [1] [https://bugs.openjdk.java.net/browse/JDK-8160247] > [2] > [https://github.com/apache/activemq-artemis/runs/2598974966?check_suite_focus=true] > [3] [https://bugs.openjdk.java.net/browse/JDK-8241047] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3027) AMQP Expiration should be persisted on the journal
[ https://issues.apache.org/jira/browse/ARTEMIS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3027: Fix Version/s: 2.17.0 > AMQP Expiration should be persisted on the journal > -- > > Key: ARTEMIS-3027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3027 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.17.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Expiration calculation should be stored on as part of the journal in AMQP. > if you set TTL, when you reboot the server the calculation would be > re-applied instead of using the previous value. > The broker should store the value instead of re-computing. > There are other scenarios where this would be an issue as well, like > appliedDelay from address settings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3027) AMQP Expiration should be persisted on the journal
[ https://issues.apache.org/jira/browse/ARTEMIS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-3027: - > AMQP Expiration should be persisted on the journal > -- > > Key: ARTEMIS-3027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3027 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Expiration calculation should be stored on as part of the journal in AMQP. > if you set TTL, when you reboot the server the calculation would be > re-applied instead of using the previous value. > The broker should store the value instead of re-computing. > There are other scenarios where this would be an issue as well, like > appliedDelay from address settings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3027) AMQP Expiration should be persisted on the journal
[ https://issues.apache.org/jira/browse/ARTEMIS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3027. --- Assignee: Clebert Suconic Resolution: Fixed > AMQP Expiration should be persisted on the journal > -- > > Key: ARTEMIS-3027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3027 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.17.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Expiration calculation should be stored on as part of the journal in AMQP. > if you set TTL, when you reboot the server the calculation would be > re-applied instead of using the previous value. > The broker should store the value instead of re-computing. > There are other scenarios where this would be an issue as well, like > appliedDelay from address settings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3367) The connector verifyHost parameter default should be changed
[ https://issues.apache.org/jira/browse/ARTEMIS-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3367: Summary: The connector verifyHost parameter default should be changed (was: The verifyHost parameter default value should be changed) > The connector verifyHost parameter default should be changed > > > Key: ARTEMIS-3367 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3367 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.17.0 >Reporter: Emmanuel Hugonnet >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently the acceptor/connector *verifyHost* parameter is set to 'false' per > default. We should provide a better out of the box experience by setting it > to true per default for connectors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3185) Various TLS tests fail on newer JDKs/environments
[
https://issues.apache.org/jira/browse/ARTEMIS-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3185.
-
Fix Version/s: 2.18.0
Resolution: Fixed
Yep, it does.
> Various TLS tests fail on newer JDKs/environments
> -
>
> Key: ARTEMIS-3185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3185
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.17.0
>Reporter: Robbie Gemmell
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.18.0
>
>
> Various broker integration tests fail after I updated to Fedora 33, seemingly
> on all JDK versions but certainly with 8u275 and above, with the failing
> tests all being TLS related. For example, AMQPConnectSaslTest,
> JMSSaslExternalTest, JMSSaslExternalLDAPTest failed, though there are others.
> Specifically, the related keystore for those tests looks to be keystore1.jks
> under tests/integration-tests/src/test/resources (though possibly other files
> in there and related tests could be affected or need updated also). The key
> contained uses SHA1withRSA for the signature, which keytool notes is disabled
> and so that is presumably the problem:
> {noformat}
> $ keytool -keystore keystore1.jks -storepass changeit -list -v
> ...snipped...
> Signature algorithm name: SHA1withRSA (disabled)
> ...snipped...
> uses the SHA1withRSA signature algorithm which is considered a
> security risk and is disabled.
> {noformat}
> I'm not clear how the file was generated and dont see the CA key used to sign
> it and which matches up to the truststore.jks file (it uses SHA256withRSA sig
> and so should be fine if the key were updated in isolation). If someone who
> knows the process used could update the key that would be great.
> A suggestion I would make is to create a script that creates the files, both
> so it can be seen later what was done, and more easily repeated and/or
> updated when needed. E.g for example we do this with the [Qpid JMS tests
> resources|https://github.com/apache/qpid-jms/blob/main/qpid-jms-client/src/test/resources/README.txt],
> which I adapted for creating the ['broker-connections' TLS
> example|https://github.com/apache/activemq-artemis/blob/master/examples/features/broker-connection/amqp-sending-overssl/store-generation.txt]
> resources when I was updating that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3410) Karaf client integration tests dont work on Java 16+
Robbie Gemmell created ARTEMIS-3410: --- Summary: Karaf client integration tests dont work on Java 16+ Key: ARTEMIS-3410 URL: https://issues.apache.org/jira/browse/ARTEMIS-3410 Project: ActiveMQ Artemis Issue Type: Bug Components: Tests Reporter: Robbie Gemmell ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing there. The karaf integration tests didnt even run on Java 11 at the time (but do now, ARTEMIS-3407), and didnt run as part of the PR build, but may soon. They will be disabled on Java 16+ until they can be made to work. In their current state the tests look to fail due to the [test] framework(s) themselves reflectively accessing elements in modules now protected by the JDK by default. Newer framework bits that dont do this, or relevant 'add opens' etc config to permit it will beneeded to address this. For the latter this looks different than other tests as it will presumably need done in the framework config within the tests themselves, not in the surefire/failsafe plugin config in the pom. Work is needed to see what can be done to get the tests running on Java 16+. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3410) Karaf client integration tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393086#comment-17393086 ] Robbie Gemmell commented on ARTEMIS-3410: - Above just disables them on 16+ for now. Leaving the JIRA open for the actual issue to be addressed. > Karaf client integration tests dont work on Java 16+ > > > Key: ARTEMIS-3410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Reporter: Robbie Gemmell >Priority: Major > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. The karaf integration tests didnt even run on Java 11 at the time (but > do now, ARTEMIS-3407), and didnt run as part of the PR build, but may soon. > They will be disabled on Java 16+ until they can be made to work. > In their current state the tests look to fail due to the [test] framework(s) > themselves reflectively accessing elements in modules now protected by the > JDK by default. Newer framework bits that dont do this, or relevant 'add > opens' etc config to permit it will beneeded to address this. For the latter > this looks different than other tests as it will presumably need done in the > framework config within the tests themselves, not in the surefire/failsafe > plugin config in the pom. Work is needed to see what can be done to get the > tests running on Java 16+. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3412) update Mockito to 3.11.2
Robbie Gemmell created ARTEMIS-3412: --- Summary: update Mockito to 3.11.2 Key: ARTEMIS-3412 URL: https://issues.apache.org/jira/browse/ARTEMIS-3412 Project: ActiveMQ Artemis Issue Type: Test Components: Tests Reporter: Robbie Gemmell Fix For: 2.18.0 update Mockito to 3.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3412) update Mockito to 3.11.2
[ https://issues.apache.org/jira/browse/ARTEMIS-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3412. - Assignee: Robbie Gemmell Resolution: Fixed > update Mockito to 3.11.2 > > > Key: ARTEMIS-3412 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3412 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > update Mockito to 3.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3418) upgrade resteasy-jaxrs dependency
[ https://issues.apache.org/jira/browse/ARTEMIS-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3418: Summary: upgrade resteasy-jaxrs dependency (was: upgrade jboss dependency) > upgrade resteasy-jaxrs dependency > - > > Key: ARTEMIS-3418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3418 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: lyndonmiao >Priority: Minor > > In 2.18.0, the project uses org.jboss.resteasy:resteasy-jaxrs of > 3.15.0.Final version, of which the latest version is 4.x. Could you upgrade > the dependency version? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3410) Karaf client integration tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-3410: - > Karaf client integration tests dont work on Java 16+ > > > Key: ARTEMIS-3410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.18.0 > > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. The karaf integration tests didnt even run on Java 11 at the time (but > do now, ARTEMIS-3407), and didnt run as part of the PR build, but may soon. > They will be disabled on Java 16+ until they can be made to work. > In their current state the tests look to fail due to the [test] framework(s) > themselves reflectively accessing elements in modules now protected by the > JDK by default. Newer framework bits that dont do this, or relevant 'add > opens' etc config to permit it will beneeded to address this. For the latter > this looks different than other tests as it will presumably need done in the > framework config within the tests themselves, not in the surefire/failsafe > plugin config in the pom. Work is needed to see what can be done to get the > tests running on Java 16+. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3410) Karaf client integration tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3410: Fix Version/s: (was: 2.18.0) Affects Version/s: 2.18.0 > Karaf client integration tests dont work on Java 16+ > > > Key: ARTEMIS-3410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. The karaf integration tests didnt even run on Java 11 at the time (but > do now, ARTEMIS-3407), and didnt run as part of the PR build, but may soon. > They will be disabled on Java 16+ until they can be made to work. > In their current state the tests look to fail due to the [test] framework(s) > themselves reflectively accessing elements in modules now protected by the > JDK by default. Newer framework bits that dont do this, or relevant 'add > opens' etc config to permit it will beneeded to address this. For the latter > this looks different than other tests as it will presumably need done in the > framework config within the tests themselves, not in the surefire/failsafe > plugin config in the pom. Work is needed to see what can be done to get the > tests running on Java 16+. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3306) artemis-cdi-client tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3306: Affects Version/s: 2.18.0 > artemis-cdi-client tests dont work on Java 16+ > -- > > Key: ARTEMIS-3306 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3306 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. It disabled running the tests for the artemis-cdi-client module to > achieve this though. > In its current state the tests fail due to an exception from Weld seemingly > failing in attempt to make a protected method in java.lang.ClassLoader > accessible, with the JVM now preventing such behaviours by default rather > than just warning on them. > If may be possible to get this going with specific module exports, or > upgrading dependencies (though these seem to have changed) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3305) compatibility tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3305: Affects Version/s: 2.18.0 > compatibility tests dont work on Java 16+ > - > > Key: ARTEMIS-3305 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3305 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. It disabled running the tests in the compatibility-tests module to > achieve this though. > In its current state, the tests look to fail primarily due to an older groovy > 2.5.x version, however upgrading this to the 3.0.8 release wasnt enough to > get things working, with the tests progressing but seeming to get into an > infinite-reconnect scenario where connection was failing and reporting a > client-server version mismatch, and eventually OOM errors etc as well. > Work is needed to see whether other changes, such as adding specific module > exports, can get the compatibility tests running on Java 16+. Its always > possible some of the previous client/server versions they use wont actually > run on 16, so perhaps even only a subset can. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3410) Karaf client integration tests dont work on Java 16+
[ https://issues.apache.org/jira/browse/ARTEMIS-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3410: Description: ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing there. The karaf integration tests didnt even run on Java 11 at the time (but do now, ARTEMIS-3407), and didnt run as part of the PR build (but do now, [828d4940|https://github.com/apache/activemq-artemis/commit/828d4940ec208c41189c650c99bd979cc7a38bd8] ). They will be disabled on Java 16+ until they can be made to work. In their current state the tests look to fail due to the [test] framework(s) themselves reflectively accessing elements in modules now protected by the JDK by default. Newer framework bits that dont do this, or relevant 'add opens' etc config to permit it will beneeded to address this. For the latter this looks different than other tests as it will presumably need done in the framework config within the tests themselves, not in the surefire/failsafe plugin config in the pom. Work is needed to see what can be done to get the tests running on Java 16+. was: ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing there. The karaf integration tests didnt even run on Java 11 at the time (but do now, ARTEMIS-3407), and didnt run as part of the PR build, but may soon. They will be disabled on Java 16+ until they can be made to work. In their current state the tests look to fail due to the [test] framework(s) themselves reflectively accessing elements in modules now protected by the JDK by default. Newer framework bits that dont do this, or relevant 'add opens' etc config to permit it will beneeded to address this. For the latter this looks different than other tests as it will presumably need done in the framework config within the tests themselves, not in the surefire/failsafe plugin config in the pom. Work is needed to see what can be done to get the tests running on Java 16+. > Karaf client integration tests dont work on Java 16+ > > > Key: ARTEMIS-3410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > > ARTEMIS-3296 enabled the build to run on Java 16 and got the PR build passing > there. The karaf integration tests didnt even run on Java 11 at the time (but > do now, ARTEMIS-3407), and didnt run as part of the PR build (but do now, > [828d4940|https://github.com/apache/activemq-artemis/commit/828d4940ec208c41189c650c99bd979cc7a38bd8] > ). They will be disabled on Java 16+ until they can be made to work. > In their current state the tests look to fail due to the [test] framework(s) > themselves reflectively accessing elements in modules now protected by the > JDK by default. Newer framework bits that dont do this, or relevant 'add > opens' etc config to permit it will beneeded to address this. For the latter > this looks different than other tests as it will presumably need done in the > framework config within the tests themselves, not in the surefire/failsafe > plugin config in the pom. Work is needed to see what can be done to get the > tests running on Java 16+. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
Robbie Gemmell created ARTEMIS-3420: --- Summary: Target Java 11+ , i.e. drop support for Java 8 Key: ARTEMIS-3420 URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Target Java 11 on the main branch. That is, drop support for building or running with Java 8 [/9/10] from future releases (e.g 2.19.0). An existing release stream (e.g. from 2.18.0 as of yesterday) could be used for continued Java 8 support where needed and occasional release for important fixes for a further period of time. This was initially proposed by Clebert ahead of 2.17.0 and discussed on the mailing list ~7 months ago (Jan 2021) in the following thread: [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] I will prod the thread with note of this JIRA and a related PR I will raise shortly. (Related note for later reference: Java 17 RC1 is out, RC2 is due later this week, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400340#comment-17400340 ] Robbie Gemmell commented on ARTEMIS-3420: - (Not setting fix-version as it doesnt exist yet, need someone with access to update them after the recent release) > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.19.0). > An existing release stream (e.g. from 2.18.0 as of yesterday) could be used > for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, RC2 is due later this > week, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3420: Comment: was deleted (was: (Not setting fix-version as it doesnt exist yet, need someone with access to update them after the recent release)) > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.19.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.19.0). > An existing release stream (e.g. from 2.18.0 as of yesterday) could be used > for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, RC2 is due later this > week, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3420: Fix Version/s: 2.19.0 > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.19.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.19.0). > An existing release stream (e.g. from 2.18.0 as of yesterday) could be used > for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, RC2 is due later this > week, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3038) Investigate CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite
[ https://issues.apache.org/jira/browse/ARTEMIS-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-3038: - > Investigate > CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite > --- > > Key: ARTEMIS-3038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3038 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > > CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite is > failing because of: > > [https://www.oracle.com/security-alerts/poodlecve-2014-3566.html] > > I set the test with an ignore .. until we investigate what we should do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3038) unwind defunct changes from ARTEMIS-1264
[ https://issues.apache.org/jira/browse/ARTEMIS-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3038: Fix Version/s: (was: 2.18.0) Affects Version/s: 2.18.0 Description: The changes made in ARTEMIS-1264 are essentially defunct and should be unwound. The Kerberos TLS cipher suites were already not recommended for use at the time due to being weak, they had already been removed entirely from Java 11 by then, and have been disabled by default in Java 8 releases for some time now. The related tests have already been removed as they were failing, then ignored, and essentialy couldnt run anywhere. The non-test changes are now untested and essentially defunct already, but once releases require Java 11 they will become entirely unusable. Originally described with "CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite is failing I set the test with an ignore .. until we investigate what we should do." was: CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite is failing because of: [https://www.oracle.com/security-alerts/poodlecve-2014-3566.html] I set the test with an ignore .. until we investigate what we should do. Summary: unwind defunct changes from ARTEMIS-1264 (was: Investigate CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite) > unwind defunct changes from ARTEMIS-1264 > > > Key: ARTEMIS-3038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3038 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Clebert Suconic >Assignee: Gary Tully >Priority: Major > > The changes made in ARTEMIS-1264 are essentially defunct and should be > unwound. The Kerberos TLS cipher suites were already not recommended for use > at the time due to being weak, they had already been removed entirely from > Java 11 by then, and have been disabled by default in Java 8 releases for > some time now. > The related tests have already been removed as they were failing, then > ignored, and essentialy couldnt run anywhere. The non-test changes are now > untested and essentially defunct already, but once releases require Java 11 > they will become entirely unusable. > > Originally described with > "CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite is > failing I set the test with an ignore .. until we investigate what we > should do." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3038) unwind defunct changes from ARTEMIS-1264
[ https://issues.apache.org/jira/browse/ARTEMIS-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400953#comment-17400953 ] Robbie Gemmell commented on ARTEMIS-3038: - Reopening per prior comment JIRA should remain open. Updated title/description for clarity to better reflect situation. > unwind defunct changes from ARTEMIS-1264 > > > Key: ARTEMIS-3038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3038 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Clebert Suconic >Assignee: Gary Tully >Priority: Major > > The changes made in ARTEMIS-1264 are essentially defunct and should be > unwound. The Kerberos TLS cipher suites were already not recommended for use > at the time due to being weak, they had already been removed entirely from > Java 11 by then, and have been disabled by default in Java 8 releases for > some time now. > The related tests have already been removed as they were failing, then > ignored, and essentialy couldnt run anywhere. The non-test changes are now > untested and essentially defunct already, but once releases require Java 11 > they will become entirely unusable. > > Originally described with > "CoreClientOverOneWaySSLKerb5Test#testOneWaySSLWithGoodClientCipherSuite is > failing I set the test with an ignore .. until we investigate what we > should do." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3421) Brokers throw TLS errors after upgrading to v2.18.0
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400981#comment-17400981
]
Robbie Gemmell commented on ARTEMIS-3421:
-
ARTEMIS-3367 changed the verifyHost setting on connectors to be true by
default, so the behaviour is expected based on your description and not a bug.
The exception is from Java's SSLEngine and is pointing out that the host being
connected to isnt advertising a certificate with details matching where the TCP
connection was made to (seemingly the raw ip of the host). You would need to
either adjust your broker config so it is connecting to a hostname value the
existing certificate details do allow matching, or alternatively update the
certificate so it can match the IP, or if not then you would need need to
explicitly disable hostname verification () to permit
the mismatch.
(It appears ARTEMIS-3367 didnt update the documentation of the default
accordingly, which should certainly be fixed.. [~brusdev] ).
> Brokers throw TLS errors after upgrading to v2.18.0
> ---
>
> Key: ARTEMIS-3421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3421
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0
>Reporter: Stephan Austermühle
>Priority: Major
>
> Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
> {code}
> 2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
> AMQ224091: Bridge ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> (identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
>
> discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
> connector=TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
> address=,
> server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
> discoveryGroupConfiguration=null]] is unable to connect to destination.
> Retrying
> 2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214016: Failed to create netty connection:
> javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
> address 100.65.179.203 found
> at java.base/sun.security.ssl.Alert.createSSLException(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
> [java.base:]
> at java.base/s
[jira] [Updated] (ARTEMIS-3423) recreated shared durable subscription is created as unshared
[ https://issues.apache.org/jira/browse/ARTEMIS-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3423: Description: This is just in the AMQP layer, if a shared durable subscription is recreated because of a change in message selector it gets created as unshared (maxconsumers=1) (was: This is just in the AMQP layer, if a durable subscription is recreated because of a change in message selector it gets created as unshared (maxconsumers=1)) Summary: recreated shared durable subscription is created as unshared (was: recreated durable subscription is created as unshared) > recreated shared durable subscription is created as unshared > > > Key: ARTEMIS-3423 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3423 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This is just in the AMQP layer, if a shared durable subscription is recreated > because of a change in message selector it gets created as unshared > (maxconsumers=1) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3421) update doc for default change in ARTEMIS-3367
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3421:
Summary: update doc for default change in ARTEMIS-3367 (was: Brokers throw
TLS errors after upgrading to v2.18.0)
> update doc for default change in ARTEMIS-3367
> -
>
> Key: ARTEMIS-3421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3421
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0
>Reporter: Stephan Austermühle
>Priority: Major
>
> Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
> {code}
> 2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
> AMQ224091: Bridge ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> (identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
>
> discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
> connector=TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
> address=,
> server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
> discoveryGroupConfiguration=null]] is unable to connect to destination.
> Retrying
> 2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214016: Failed to create netty connection:
> javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
> address 100.65.179.203 found
> at java.base/sun.security.ssl.Alert.createSSLException(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at java.base/java.security.AccessController.doPrivileged(Native
> Method) [java.base:]
> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown
> Source) [java.base:]
> at
> io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1550)
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1396)
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
>
[jira] [Updated] (ARTEMIS-3421) update doc for default change in ARTEMIS-3367
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3421:
Component/s: (was: Broker)
Configuration
Fix Version/s: 2.19.0
Description:
The changes in ARTEMIS-3367 flipped the connector verifyHost default config,
but did not update the docs to reflect the new default value.
Original Description:
Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
{code:java}
2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
AMQ224091: Bridge ClusterConnectionBridge@40455191
[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
(identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
[initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
connector=TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
address=, server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
[initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
discoveryGroupConfiguration=null]] is unable to connect to destination.
Retrying
2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
AMQ214016: Failed to create netty connection:
javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
address 100.65.179.203 found
at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
Source) [java.base:]
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
[java.base:]
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source) [java.base:]
at java.base/java.security.AccessController.doPrivileged(Native Method)
[java.base:]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown
Source) [java.base:]
at
io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1550)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1396)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1237)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1286)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
[netty-all-4.1.66.Final.jar:4.1.66
[jira] [Resolved] (ARTEMIS-3421) update doc for default change in ARTEMIS-3367
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3421.
-
Resolution: Fixed
> update doc for default change in ARTEMIS-3367
> -
>
> Key: ARTEMIS-3421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3421
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.18.0
>Reporter: Stephan Austermühle
>Priority: Major
> Fix For: 2.19.0
>
>
> The changes in ARTEMIS-3367 flipped the connector verifyHost default config,
> but did not update the docs to reflect the new default value.
>
> =
> Original Description:
> Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
> {code:java}
> 2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
> AMQ224091: Bridge ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> (identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
>
> discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
> connector=TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
> address=,
> server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
> discoveryGroupConfiguration=null]] is unable to connect to destination.
> Retrying
> 2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214016: Failed to create netty connection:
> javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
> address 100.65.179.203 found
> at java.base/sun.security.ssl.Alert.createSSLException(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at java.base/java.security.AccessController.doPrivileged(Native
> Method) [java.base:]
> at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown
> Source) [java.base:]
> at
> io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1550)
> [netty-all-4.1.66.Final.j
[jira] [Updated] (ARTEMIS-3421) update doc for default change in ARTEMIS-3367
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3421:
Description:
The changes in ARTEMIS-3367 flipped the connector verifyHost default config,
but did not update the docs to reflect the new default value.
=
Original Description:
Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
{code:java}
2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
AMQ224091: Bridge ClusterConnectionBridge@40455191
[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
(identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
[initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
connector=TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
address=, server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
[initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
discoveryGroupConfiguration=null]] is unable to connect to destination.
Retrying
2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
AMQ214016: Failed to create netty connection:
javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
address 100.65.179.203 found
at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
[java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
Source) [java.base:]
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
[java.base:]
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
[java.base:]
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source) [java.base:]
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source) [java.base:]
at java.base/java.security.AccessController.doPrivileged(Native Method)
[java.base:]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown
Source) [java.base:]
at
io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1550)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1396)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1237)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1286)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(Byte
[jira] [Commented] (ARTEMIS-3421) update doc for default change in ARTEMIS-3367
[
https://issues.apache.org/jira/browse/ARTEMIS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401209#comment-17401209
]
Robbie Gemmell commented on ARTEMIS-3421:
-
The docs change will be in the next release, but Clebert has refreshed the
version on the website for 2.18.0 to include the update now.
> update doc for default change in ARTEMIS-3367
> -
>
> Key: ARTEMIS-3421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3421
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.18.0
>Reporter: Stephan Austermühle
>Priority: Major
> Fix For: 2.19.0
>
>
> The changes in ARTEMIS-3367 flipped the connector verifyHost default config,
> but did not update the docs to reflect the new default value.
>
> =
> Original Description:
> Brokers throw TLS verification exceptions after upgrading to Artemis v2.18.0
> {code:java}
> 2021-08-18 10:15:41,933 WARN [org.apache.activemq.artemis.core.server]
> AMQ224091: Bridge ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> (identity=(Cluster-connection-bridge::ClusterConnectionBridge@40455191
> [name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
>
> queue=QueueImpl[name=$.artemis.internal.sf.artemis-cluster.12adae96-fe90-11eb-807e-0ad2880c8414,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0],
> temp=false]@6ed36dc2 targetConnector=ServerLocatorImpl
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
>
> discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1573349881[nodeUUID=12e511ec-fe90-11eb-898f-c26f402d9363,
> connector=TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-72-25&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576,
> address=,
> server=ActiveMQServerImpl::name=ha-asa-activemq-artemis-primary-0]))
> [initialConnectors=[TransportConfiguration(name=artemis-tls-connector,
> factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory)
>
> ?trustStorePassword=&tcpReceiveBufferSize=1048576&port=61617&sslEnabled=true&host=100-65-179-203&trustStorePath=/var/lib/artemis/certs/truststore-jks&useEpoll=true&tcpSendBufferSize=1048576],
> discoveryGroupConfiguration=null]] is unable to connect to destination.
> Retrying
> 2021-08-18 10:15:42,001 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214016: Failed to create netty connection:
> javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP
> address 100.65.179.203 found
> at java.base/sun.security.ssl.Alert.createSSLException(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
> [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown
> Source) [java.base:]
> at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
> [java.base:]
> at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
> Source) [java.base:]
> at java.base/java.security.AccessController.doPrivileged(Native
> Method) [java.base:]
> at java.base/sun.security.ssl.SSLEngine
[jira] [Commented] (AMQ-8357) Download page for 5.16.3 refers to MD5; must not link to Git
[ https://issues.apache.org/jira/browse/AMQ-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401577#comment-17401577 ] Robbie Gemmell commented on AMQ-8357: - It also links to the 5.16.2 release notes. > Download page for 5.16.3 refers to MD5; must not link to Git > > > Key: AMQ-8357 > URL: https://issues.apache.org/jira/browse/AMQ-8357 > Project: ActiveMQ > Issue Type: Bug >Reporter: Sebb >Assignee: Jean-Baptiste Onofré >Priority: Major > > The download page [1] refers several times to MD5. Such hashes are > deprecated, and are not actually used by AMQ any more. > Please update the instructions so that they can be used by downloaders. > Also Git repos must not be linked from download pages, as they contain code > that has not been formally released. > Note also that MD5 is not a signature (nor are SHA*) - they are hashes. > The PGP asc file is a signature. > [1] https://activemq.apache.org/activemq-5016003-release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite
Robbie Gemmell created ARTEMIS-3435:
---
Summary: ActiveMQTestBase.checkLibaio waits can cause hours to be
added to failing test suite
Key: ARTEMIS-3435
URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
Project: ActiveMQ Artemis
Issue Type: Test
Components: Tests
Affects Versions: 2.18.0
Reporter: Robbie Gemmell
I recently observered a 'full test' run take over an extra 3 hours, essentially
doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins), with nearly
450 failures in the integration-tests module mostly all due to the same 'test
did not close all its files 4096' reason.
Investigating, I found that all the failures appeared linked and were likely
caused by a single prior test having done something awry, with the effect then
continuing to fail all subsequent tests classes (after they had run their
tests, successfully or otherwise) using the same ActiveMQTestBase parent class
for the same reason. Before invoking the fail it waits 30 seconds for the
ActiveMQTestBase.checkLibaio check to assert a value hits 0after the test
class, which it repeatedly didnt. This added 400+ 30sec waits to the test run,
failing those 400+ test classes.
I wasnt able to get all the classes in the output summary, the continued test
output filled the buffer, but I got a couple snippets:
{noformat}
[ERROR] Failures:
[ERROR]
QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
msg must exist
[ERROR]
PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
...lots missing...
{noformat}
{noformat}
...lots missing...
[ERROR]
FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR] MqttPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] OpenwirePluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
ResourceBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] StompPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] XmlConfigPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
ActiveMQActivationTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] ActiveMQClusteredTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
ActiveMQMessageHandlerSecurityTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
ActiveMQMessageHandlerTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
ActiveMQMessageHandlerXATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR] IgnoreJTATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR] JMSContextTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
did not close all its files 4096
[ERROR]
OutgoingConnectionJTATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
test did not close all its files 4096
[ERROR]
OutgoingCon
[jira] [Commented] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite
[
https://issues.apache.org/jira/browse/ARTEMIS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402275#comment-17402275
]
Robbie Gemmell commented on ARTEMIS-3435:
-
The check is operating on a static valid that is incremented and decremented as
the LibaioContext instances are created and closed. If a single instance fails
to be cleaned up correct, all subsequent test classes using ActiveMQTestBase
fail, after 30 seconds of waiting in the cleanup.
The fact it is static means it isnt easy to account around a prior failure as
change may still happen after a delayed time, and it is hard to identify
whether it happened in the detecting class or a previous one that perhaps
doesnt use ActiveMQTestBase, so I think the simplest thing for now is to make
the detail available the clearest it can be, and fail things as fast as
possible instead of taking hours extra, helping reduce the vast amount of
output and narrowing down a window when the issue occurred that could then be
looked at more closely.
I have prepared a patch so the after class check will now record the failure if
it is >0 after 1 wait, then future classes will fail immediately without
running, reporting the class that detected the issue so its logs can be
checked. Prior to this they will also log if the value was 0 before the class
started (in case it is a non-ActiveMQTestBase class causing it).
> ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing
> test suite
>
>
> Key: ARTEMIS-3435
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> I recently observered a 'full test' run take over an extra 3 hours,
> essentially doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins),
> with nearly 450 failures in the integration-tests module mostly all due to
> the same 'test did not close all its files 4096' reason.
> Investigating, I found that all the failures appeared linked and were likely
> caused by a single prior test having done something awry, with the effect
> then continuing to fail all subsequent tests classes (after they had run
> their tests, successfully or otherwise) using the same ActiveMQTestBase
> parent class for the same reason. Before invoking the fail it waits 30
> seconds for the ActiveMQTestBase.checkLibaio check to assert a value hits
> 0after the test class, which it repeatedly didnt. This added 400+ 30sec waits
> to the test run, failing those 400+ test classes.
> I wasnt able to get all the classes in the output summary, the continued test
> output filled the buffer, but I got a couple snippets:
> {noformat}
> [ERROR] Failures:
> [ERROR]
> QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
> msg must exist
> [ERROR]
> PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> ...lots missing...
> {noformat}
> {noformat}
> ...lots missing...
> [ERROR]
> FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
> did not close all its files 4096
> [ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->As
[jira] [Created] (ARTEMIS-3440) separate effect of -Pdev from -Ptests
Robbie Gemmell created ARTEMIS-3440: --- Summary: separate effect of -Pdev from -Ptests Key: ARTEMIS-3440 URL: https://issues.apache.org/jira/browse/ARTEMIS-3440 Project: ActiveMQ Artemis Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.19.0 Currently the build has RAT and checkstyle executions always configured, but uses some artemis specific properties to skip them by default. These properties are then used in the 'tests', fast-tests', and 'dev' profiles to enable the checks when the profile is activated. This approach means that: - If you use the test profiles (needed to run tests), you get the dev checks even if you dont want. - You cant skip or not-skip the checks even with their own well known skip properties. - You cant run the check directly with its own mojo, without first hunting down an artemis specific property to also not-skip them so they actually run. The former in particular can be annoying when developing and running specific tests repeatedly, as it adds >10sec before the execution of a specified integration test for example. It also prevents an improvement I was looking to do for the GHA CI jobs where the checks are run in isolation from the tests (ensures the tests start and complete as fast as possible, speeding things up overall, makes the checks not prevent the tests running if they fail, and vice versa ensures the checks occur regardless of the tests failing which happens somewhat often at times). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3440) separate effect of -Pdev from -Ptests
[ https://issues.apache.org/jira/browse/ARTEMIS-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3440. - Resolution: Fixed > separate effect of -Pdev from -Ptests > - > > Key: ARTEMIS-3440 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3440 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.19.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the build has RAT and checkstyle executions always configured, but > uses some artemis specific properties to skip them by default. These > properties are then used in the 'tests', fast-tests', and 'dev' profiles to > enable the checks when the profile is activated. > This approach means that: > - If you use the test profiles (needed to run tests), you get the dev checks > even if you dont want. > - You cant skip or not-skip the checks even with their own well known skip > properties. > - You cant run the check directly with its own mojo, without first hunting > down an artemis specific property to also not-skip them so they actually run. > The former in particular can be annoying when developing and running specific > tests repeatedly, as it adds >10sec before the execution of a specified > integration test for example. > It also prevents an improvement I was looking to do for the GHA CI jobs where > the checks are run in isolation from the tests (ensures the tests start and > complete as fast as possible, speeding things up overall, makes the checks > not prevent the tests running if they fail, and vice versa ensures the checks > occur regardless of the tests failing which happens somewhat often at times). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3447) update version of bcprov-jdk15on used by Directory in tests
Robbie Gemmell created ARTEMIS-3447: --- Summary: update version of bcprov-jdk15on used by Directory in tests Key: ARTEMIS-3447 URL: https://issues.apache.org/jira/browse/ARTEMIS-3447 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.19.0 Some of the tests use an older version of the bouncycastle bcprov-jdk15on dependency via their use of Directory, use a dependencyManagement entry to move them to a current version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3447) update version of bcprov-jdk15on used by Directory in tests
[ https://issues.apache.org/jira/browse/ARTEMIS-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3447. - Resolution: Fixed > update version of bcprov-jdk15on used by Directory in tests > --- > > Key: ARTEMIS-3447 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3447 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.19.0 > > > Some of the tests use an older version of the bouncycastle bcprov-jdk15on > dependency via their use of Directory, use a dependencyManagement entry to > move them to a current version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
Robbie Gemmell created ARTEMIS-3450: --- Summary: StaticPoolTest and DiscoveryPoolTest fail sporadically in CI Key: ARTEMIS-3450 URL: https://issues.apache.org/jira/browse/ARTEMIS-3450 Project: ActiveMQ Artemis Issue Type: Test Components: Tests Reporter: Robbie Gemmell The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail sporadically in CI Some examples: https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325 https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223 Looking at the tests I do see a few small issues, though they may not explain the failures: - The MockTargetProbe contains a HashMap used from multiple threads (test and pool) in a manner that isnt thread safe. It actually threw ConcurrentModificationException during at least one CI run (e.g https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163). That may or may not be the cause of the test failure seen in the same log (note it isnt seen in the other test log, though it failed at a different assertion). It should use ConcurrentHashMap or perhaps alternatively protect use of the map more generally. - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts a pool but doesnt ensure it is stopped on assertion failure. The DiscoveryPoolTest subclass runs this test with a pool using a scheduled executor, so it should presumably be cleaned up in the same manner the other tests all use. - One of the tests asserts there are no 'createdTargets' entries, and then immediately iterates those [non-existent] entries to assert on the non-existent values, which seems quite strange. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
[ https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3450: Affects Version/s: 2.18.0 > StaticPoolTest and DiscoveryPoolTest fail sporadically in CI > > > Key: ARTEMIS-3450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3450 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > > The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail > sporadically in CI > Some examples: > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325 > https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223 > Looking at the tests I do see a few small issues, though they may not explain > the failures: > - The MockTargetProbe contains a HashMap used from multiple threads (test and > pool) in a manner that isnt thread safe. It actually threw > ConcurrentModificationException during at least one CI run (e.g > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163). > That may or may not be the cause of the test failure seen in the same log > (note it isnt seen in the other test log, though it failed at a different > assertion). It should use ConcurrentHashMap or perhaps alternatively protect > use of the map more generally. > - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts > a pool but doesnt ensure it is stopped on assertion failure. The > DiscoveryPoolTest subclass runs this test with a pool using a scheduled > executor, so it should presumably be cleaned up in the same manner the other > tests all use. > - One of the tests asserts there are no 'createdTargets' entries, and then > immediately iterates those [non-existent] entries to assert on the > non-existent values, which seems quite strange. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
[
https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406680#comment-17406680
]
Robbie Gemmell commented on ARTEMIS-3450:
-
Diff to help show the noted issues (which again, dont necessarily explain the
failures):
{noformat}
diff --git
a/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/pools/PoolTestBase.java
b/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/pools/PoolTestBase.java
index 1f7505ebd8..4d1099953a 100644
---
a/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/pools/PoolTestBase.java
+++
b/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/pools/PoolTestBase.java
@@ -65,24 +65,28 @@ public abstract class PoolTestBase {
pool.start();
- Wait.assertEquals(targets, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
+ try {
+ Wait.assertEquals(targets, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
- targetFactory.getCreatedTargets().stream().limit(targets - quorumSize +
1)
- .forEach(mockTarget -> mockTarget.setReady(false));
+ targetFactory.getCreatedTargets().stream().limit(targets -
quorumSize + 1)
+ .forEach(mockTarget -> mockTarget.setReady(false));
- Wait.assertEquals(0, () -> pool.getTargets().size(), CHECK_TIMEOUT);
+ Wait.assertEquals(0, () -> pool.getTargets().size(), CHECK_TIMEOUT);
- targetFactory.getCreatedTargets().get(0).setReady(true);
+ targetFactory.getCreatedTargets().get(0).setReady(true);
- Wait.assertEquals(quorumSize, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
+ Wait.assertEquals(quorumSize, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
- pool.setQuorumSize(quorumSize + 1);
+ pool.setQuorumSize(quorumSize + 1);
- Wait.assertEquals(0, () -> pool.getTargets().size(), CHECK_TIMEOUT);
+ Wait.assertEquals(0, () -> pool.getTargets().size(), CHECK_TIMEOUT);
- targetFactory.getCreatedTargets().get(1).setReady(true);
+ targetFactory.getCreatedTargets().get(1).setReady(true);
- Wait.assertEquals(quorumSize + 1, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
+ Wait.assertEquals(quorumSize + 1, () -> pool.getTargets().size(),
CHECK_TIMEOUT);
+ } finally {
+ pool.stop();
+ }
}
@@ -96,10 +100,6 @@ public abstract class PoolTestBase {
Assert.assertEquals(0, pool.getTargets().size());
Assert.assertEquals(0, pool.getAllTargets().size());
Assert.assertEquals(0, targetFactory.getCreatedTargets().size());
- targetFactory.getCreatedTargets().forEach(mockTarget -> {
- Assert.assertFalse(pool.isTargetReady(mockTarget));
- Assert.assertEquals(0, targetProbe.getTargetExecutions(mockTarget));
- });
pool.start();
diff --git
a/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/targets/MockTargetProbe.java
b/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/targets/MockTargetProbe.java
index d8c3aa2e48..eee0caf422 100644
---
a/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/targets/MockTargetProbe.java
+++
b/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/balancing/targets/MockTargetProbe.java
@@ -17,11 +17,11 @@
package org.apache.activemq.artemis.core.server.balancing.targets;
-import java.util.HashMap;
import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
public class MockTargetProbe extends TargetProbe {
- private final Map targetExecutions = new HashMap<>();
+ private final Map targetExecutions = new
ConcurrentHashMap<>();
private boolean checked;
{noformat}
> StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
>
>
> Key: ARTEMIS-3450
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3450
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail
> sporadically in CI
> Some examples:
> https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325
> https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223
> Looking at the tests I do see a few small issues, though they may not explain
> the failures:
> - The MockTargetProbe contains a HashMap used from multiple threads (test and
> pool) in a manner that isnt thread safe. It actually threw
> ConcurrentModificationException during at least one CI run (e.g
> https://github.com/apache/activemq-
[jira] [Created] (ARTEMIS-3451) add dependencyManagement entry to consolidate versioning for qpid-jms-client usage
Robbie Gemmell created ARTEMIS-3451: --- Summary: add dependencyManagement entry to consolidate versioning for qpid-jms-client usage Key: ARTEMIS-3451 URL: https://issues.apache.org/jira/browse/ARTEMIS-3451 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.18.0 Reporter: Robbie Gemmell Fix For: 2.19.0 The codebase uses qpid-jms-client in many places, cli, tests, examples, etc. Nearly every use is specifying a version directly, albeit from the a property. A dependencyManagement entry should be used to consolidate and simplify most of the related version config. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3451) add dependencyManagement entry to consolidate versioning for qpid-jms-client usage
[ https://issues.apache.org/jira/browse/ARTEMIS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3451. - Resolution: Fixed > add dependencyManagement entry to consolidate versioning for qpid-jms-client > usage > -- > > Key: ARTEMIS-3451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3451 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Minor > Fix For: 2.19.0 > > > The codebase uses qpid-jms-client in many places, cli, tests, examples, etc. > Nearly every use is specifying a version directly, albeit from the a > property. A dependencyManagement entry should be used to consolidate and > simplify most of the related version config. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3453) exclude transitive log4j dep from zookeeper usage
Robbie Gemmell created ARTEMIS-3453: --- Summary: exclude transitive log4j dep from zookeeper usage Key: ARTEMIS-3453 URL: https://issues.apache.org/jira/browse/ARTEMIS-3453 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.18.0 Reporter: Robbie Gemmell Fix For: 2.19.0 The quorum bits introduced in ARTEMIS-2716 in 2.18.0 use Zookeeper, which brings a transitive dependency on log4j 1.2.17, which is end of life. Although log4j 1.2.17 was not included in the distribution archives, it still a transitive dependency of some of the modules that use these quorum bits. The original change does look to exclude slf4j-log4j12, but this doesnt exclude log4j itself which is also a direct dependency of zookeeper (ironically, it seems not for direct logging, but only some JMX feature, with slf4j used for the actual logging). It should also be excluded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3453) exclude transitive log4j dep from zookeeper usage
[ https://issues.apache.org/jira/browse/ARTEMIS-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3453. - Resolution: Fixed > exclude transitive log4j dep from zookeeper usage > - > > Key: ARTEMIS-3453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3453 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.19.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The quorum bits introduced in ARTEMIS-2716 in 2.18.0 use Zookeeper, which > brings a transitive dependency on log4j 1.2.17, which is end of life. > Although log4j 1.2.17 was not included in the distribution archives, it still > a transitive dependency of some of the modules that use these quorum bits. > The original change does look to exclude slf4j-log4j12, but this doesnt > exclude log4j itself which is also a direct dependency of zookeeper > (ironically, it seems not for direct logging, but only some JMX feature, with > slf4j used for the actual logging). It should also be excluded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3453) exclude transitive log4j dep from zookeeper usage
[ https://issues.apache.org/jira/browse/ARTEMIS-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-3453: --- Assignee: Robbie Gemmell > exclude transitive log4j dep from zookeeper usage > - > > Key: ARTEMIS-3453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3453 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.19.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The quorum bits introduced in ARTEMIS-2716 in 2.18.0 use Zookeeper, which > brings a transitive dependency on log4j 1.2.17, which is end of life. > Although log4j 1.2.17 was not included in the distribution archives, it still > a transitive dependency of some of the modules that use these quorum bits. > The original change does look to exclude slf4j-log4j12, but this doesnt > exclude log4j itself which is also a direct dependency of zookeeper > (ironically, it seems not for direct logging, but only some JMX feature, with > slf4j used for the actual logging). It should also be excluded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
[ https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408951#comment-17408951 ] Robbie Gemmell commented on ARTEMIS-3450: - [https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c7b672d] by [~gtully] on ARTEMIS-3365 is presumably related. > StaticPoolTest and DiscoveryPoolTest fail sporadically in CI > > > Key: ARTEMIS-3450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3450 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Assignee: Domenico Francesco Bruscino >Priority: Major > > The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail > sporadically in CI > Some examples: > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325 > https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223 > Looking at the tests I do see a few small issues, though they may not explain > the failures: > - The MockTargetProbe contains a HashMap used from multiple threads (test and > pool) in a manner that isnt thread safe. It actually threw > ConcurrentModificationException during at least one CI run (e.g > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163). > That may or may not be the cause of the test failure seen in the same log > (note it isnt seen in the other test log, though it failed at a different > assertion). It should use ConcurrentHashMap or perhaps alternatively protect > use of the map more generally. > - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts > a pool but doesnt ensure it is stopped on assertion failure. The > DiscoveryPoolTest subclass runs this test with a pool using a scheduled > executor, so it should presumably be cleaned up in the same manner the other > tests all use. > - One of the tests asserts there are no 'createdTargets' entries, and then > immediately iterates those [non-existent] entries to assert on the > non-existent values, which seems quite strange. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite
[
https://issues.apache.org/jira/browse/ARTEMIS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3435.
-
Fix Version/s: 2.19.0
Assignee: Robbie Gemmell
Resolution: Fixed
> ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing
> test suite
>
>
> Key: ARTEMIS-3435
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.19.0
>
>
> I recently observered a 'full test' run take over an extra 3 hours,
> essentially doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins),
> with nearly 450 failures in the integration-tests module mostly all due to
> the same 'test did not close all its files 4096' reason.
> Investigating, I found that all the failures appeared linked and were likely
> caused by a single prior test having done something awry, with the effect
> then continuing to fail all subsequent tests classes (after they had run
> their tests, successfully or otherwise) using the same ActiveMQTestBase
> parent class for the same reason. Before invoking the fail it waits 30
> seconds for the ActiveMQTestBase.checkLibaio check to assert a value hits
> 0after the test class, which it repeatedly didnt. This added 400+ 30sec waits
> to the test run, failing those 400+ test classes.
> I wasnt able to get all the classes in the output summary, the continued test
> output filled the buffer, but I got a couple snippets:
> {noformat}
> [ERROR] Failures:
> [ERROR]
> QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
> msg must exist
> [ERROR]
> PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> ...lots missing...
> {noformat}
> {noformat}
> ...lots missing...
> [ERROR]
> FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
> did not close all its files 4096
> [ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] MqttPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
> did not close all its files 4096
> [ERROR] OpenwirePluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> ResourceBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] StompPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR] XmlConfigPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> ActiveMQActivationTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
> did not close all its files 4096
> [ERROR]
> ActiveMQClusteredTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test
> did not close all its files 4096
> [ERROR]
> ActiveMQMessageHandlerSecurityTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
> test did not close all its files 4096
> [ERROR]
> ActiveMQMessageHandlerTest>ActiveMQTestBase.checkLibaio:2061
[jira] [Updated] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3420: Fix Version/s: (was: 2.19.0) 2.20.0 > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.20.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.19.0). > An existing release stream (e.g. from 2.18.0 as of yesterday) could be used > for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, RC2 is due later this > week, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3420) Target Java 11+ , i.e. drop support for Java 8
[ https://issues.apache.org/jira/browse/ARTEMIS-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3420: Description: Target Java 11 on the main branch. That is, drop support for building or running with Java 8 [/9/10] from future releases (e.g 2.20.0). An existing release stream (e.g. from 2.18.0 as of report, 2.19.0 soon) could be used for continued Java 8 support where needed and occasional release for important fixes for a further period of time. This was initially proposed by Clebert ahead of 2.17.0 and discussed on the mailing list ~7 months ago (Jan 2021) in the following thread: [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] I will prod the thread with note of this JIRA and a related PR I will raise shortly. (Related note for later reference: Java 17 RC1 is out, -RC2 is due later this week-, and final release is due in just under a month) was: Target Java 11 on the main branch. That is, drop support for building or running with Java 8 [/9/10] from future releases (e.g 2.19.0). An existing release stream (e.g. from 2.18.0 as of yesterday) could be used for continued Java 8 support where needed and occasional release for important fixes for a further period of time. This was initially proposed by Clebert ahead of 2.17.0 and discussed on the mailing list ~7 months ago (Jan 2021) in the following thread: [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] I will prod the thread with note of this JIRA and a related PR I will raise shortly. (Related note for later reference: Java 17 RC1 is out, RC2 is due later this week, and final release is due in just under a month) > Target Java 11+ , i.e. drop support for Java 8 > -- > > Key: ARTEMIS-3420 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3420 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.20.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Target Java 11 on the main branch. That is, drop support for building or > running with Java 8 [/9/10] from future releases (e.g 2.20.0). > An existing release stream (e.g. from 2.18.0 as of report, 2.19.0 soon) could > be used for continued Java 8 support where needed and occasional release for > important fixes for a further period of time. > This was initially proposed by Clebert ahead of 2.17.0 and discussed on the > mailing list ~7 months ago (Jan 2021) in the following thread: > > [https://lists.apache.org/thread.html/re59ba50c9d148d278e88d435f57f5cd4b4b69802138eb962b548ec48%40%3Cdev.activemq.apache.org%3E] > I will prod the thread with note of this JIRA and a related PR I will raise > shortly. > > (Related note for later reference: Java 17 RC1 is out, -RC2 is due later this > week-, and final release is due in just under a month) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
[ https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408951#comment-17408951 ] Robbie Gemmell edited comment on ARTEMIS-3450 at 9/3/21, 1:52 PM: -- [https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c7b672d] by [~gtully] on ARTEMIS-3365 is presumably related. (Edit: though did not resolve the failures, a subsequent build https://github.com/apache/activemq-artemis/runs/3499254127?check_suite_focus=true#step:5:2154) was (Author: gemmellr): [https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c7b672d] by [~gtully] on ARTEMIS-3365 is presumably related. > StaticPoolTest and DiscoveryPoolTest fail sporadically in CI > > > Key: ARTEMIS-3450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3450 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Assignee: Domenico Francesco Bruscino >Priority: Major > > The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail > sporadically in CI > Some examples: > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325 > https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223 > Looking at the tests I do see a few small issues, though they may not explain > the failures: > - The MockTargetProbe contains a HashMap used from multiple threads (test and > pool) in a manner that isnt thread safe. It actually threw > ConcurrentModificationException during at least one CI run (e.g > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163). > That may or may not be the cause of the test failure seen in the same log > (note it isnt seen in the other test log, though it failed at a different > assertion). It should use ConcurrentHashMap or perhaps alternatively protect > use of the map more generally. > - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts > a pool but doesnt ensure it is stopped on assertion failure. The > DiscoveryPoolTest subclass runs this test with a pool using a scheduled > executor, so it should presumably be cleaned up in the same manner the other > tests all use. > - One of the tests asserts there are no 'createdTargets' entries, and then > immediately iterates those [non-existent] entries to assert on the > non-existent values, which seems quite strange. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3458) CuratorDistributedLockTest fails a lot in CI
Robbie Gemmell created ARTEMIS-3458:
---
Summary: CuratorDistributedLockTest fails a lot in CI
Key: ARTEMIS-3458
URL: https://issues.apache.org/jira/browse/ARTEMIS-3458
Project: ActiveMQ Artemis
Issue Type: Test
Components: Tests
Affects Versions: 2.18.0
Reporter: Robbie Gemmell
Assignee: Francesco Nigro
CuratorDistributedLockTest was added in ARTEMIS-2716 / [PR
#3680|https://github.com/apache/activemq-artemis/pull/3680]. In addition to
creating a lot of log output which made the Travis build error and required
some changes, it fails a lot in CI.
E.g perhaps most often with:
{noformat}
org.apache.curator.test.FailedServerStartException: quorumPeer never got set
at
org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedLockTest.setupEnv(CuratorDistributedLockTest.java:84)
{noformat}
[https://github.com/apache/activemq-artemis/runs/3496677873?check_suite_focus=true#step:5:58742]
Or I also saw:
{noformat}
java.lang.AssertionError: expected:<1> but was:<0>
at
org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedLockTest.beNotifiedOfUnavailabilityWhileBlockedOnTimedLock(CuratorDistributedLockTest.java:309)
{noformat}
[https://github.com/apache/activemq-artemis/runs/3495287001?check_suite_focus=true#step:5:56488]
Finally, today I saw it fail a completely new way, taking down the test JVM:
{noformat}
[QuorumPeerListener] 09:43:44,204 ERROR
[org.apache.zookeeper.util.ServiceUtils] Exiting JVM with code 14
{noformat}
[https://github.com/apache/activemq-artemis/runs/3504709670?check_suite_focus=true#step:5:35957]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3459) AMQPMessage.scanMessageData() creates unecessary buffer wrapper
Robbie Gemmell created ARTEMIS-3459:
---
Summary: AMQPMessage.scanMessageData() creates unecessary buffer
wrapper
Key: ARTEMIS-3459
URL: https://issues.apache.org/jira/browse/ARTEMIS-3459
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.18.0
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Fix For: 2.19.0
The AMQPMessage.scanMessageData(ReadableBuffer) method creates an unecessary
buffer wrapper on every decode. The method has the equivalent of:
{code}
decoder.setBuffer(data);
try {
//...use decoder..
} finally {
decoder.setByteBuffer(null);
}
{code}
Effectively it tries to use the thread-local decoder, then ensure the related
buffer is discarded after.
However the two setter uses are different, with the former taking the
ReadableBuffer directly, and the latter method expected to be passed a
ByteBuffer, which causes creation of a ReadableBuffer wrapper for it. By
passing it null with that method, a needless wrapper object is created. One
which is discarded on the next decode by that thread when it sets the next
actual buffer. It should be using setBuffer(null).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3459) AMQPMessage.scanMessageData() creates unecessary buffer wrapper
[
https://issues.apache.org/jira/browse/ARTEMIS-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3459.
-
Resolution: Fixed
> AMQPMessage.scanMessageData() creates unecessary buffer wrapper
> ---
>
> Key: ARTEMIS-3459
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3459
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Trivial
> Fix For: 2.19.0
>
>
> The AMQPMessage.scanMessageData(ReadableBuffer) method creates an unecessary
> buffer wrapper on every decode. The method has the equivalent of:
> {code}
> decoder.setBuffer(data);
> try {
>//...use decoder..
> } finally {
>decoder.setByteBuffer(null);
> }
> {code}
> Effectively it tries to use the thread-local decoder, then ensure the related
> buffer is discarded after.
> However the two setter uses are different, with the former taking the
> ReadableBuffer directly, and the latter method expected to be passed a
> ByteBuffer, which causes creation of a ReadableBuffer wrapper for it. By
> passing it null with that method, a needless wrapper object is created. One
> which is discarded on the next decode by that thread when it sets the next
> actual buffer. It should be using setBuffer(null).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3286) address or queue with COMMA is displayed wrong in web console
[
https://issues.apache.org/jira/browse/ARTEMIS-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3286.
---
Resolution: Fixed
> address or queue with COMMA is displayed wrong in web console
> -
>
> Key: ARTEMIS-3286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3286
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.17.0
>Reporter: Erwin Dondorp
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.18.0
>
> Attachments: image-2021-05-06-22-35-19-449.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> when creating an address with a COMMA in its name, the address is displayed
> in an odd fashion.
> Use "Create address" and enter {{x,y}} (i.e. x-comma-y)
> See:
> !image-2021-05-06-22-35-19-449.png!
> A similar thing happens for queues containing a COMMA.
> NOTE:
> I normally do not create objects with a COMMA in their name, but the
> commandline does.
> e.g.: {{artemis consumer --destination topic://foobar --durable --clientID
> myclientid}}
> This creates a queue named {{myclientid.Consumer ActiveMQTopic[foobar],
> thread=0}} under the given address.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3450) StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
[ https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-3450. - Fix Version/s: 2.19.0 Resolution: Fixed > StaticPoolTest and DiscoveryPoolTest fail sporadically in CI > > > Key: ARTEMIS-3450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3450 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Affects Versions: 2.18.0 >Reporter: Robbie Gemmell >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.19.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail > sporadically in CI > Some examples: > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325 > https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223 > Looking at the tests I do see a few small issues, though they may not explain > the failures: > - The MockTargetProbe contains a HashMap used from multiple threads (test and > pool) in a manner that isnt thread safe. It actually threw > ConcurrentModificationException during at least one CI run (e.g > https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163). > That may or may not be the cause of the test failure seen in the same log > (note it isnt seen in the other test log, though it failed at a different > assertion). It should use ConcurrentHashMap or perhaps alternatively protect > use of the map more generally. > - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts > a pool but doesnt ensure it is stopped on assertion failure. The > DiscoveryPoolTest subclass runs this test with a pool using a scheduled > executor, so it should presumably be cleaned up in the same manner the other > tests all use. > - One of the tests asserts there are no 'createdTargets' entries, and then > immediately iterates those [non-existent] entries to assert on the > non-existent values, which seems quite strange. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3473) Testsuite leaving "null" folder behind
[ https://issues.apache.org/jira/browse/ARTEMIS-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414007#comment-17414007 ] Robbie Gemmell commented on ARTEMIS-3473: - I'm going to assume this resolves ARTEMIS-3301 and close it also. > Testsuite leaving "null" folder behind > -- > > Key: ARTEMIS-3473 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3473 > Project: ActiveMQ Artemis > Issue Type: Test >Affects Versions: 2.18.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.19.0 > > > some tests were overriding ActiveMQTestBase::setUp and not allowing the > testDir property to be filled, making the test to create the journal in wrong > places eventually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3301) Some integration tests leave files in the source tree making further runs fail
[ https://issues.apache.org/jira/browse/ARTEMIS-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3301. --- Resolution: Duplicate Assuming this was fixed by ARTEMIS-3473 and closing, can always reopen if needed. > Some integration tests leave files in the source tree making further runs fail > -- > > Key: ARTEMIS-3301 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3301 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Tests >Reporter: Robbie Gemmell >Priority: Major > > I did a test run using "mvn clean install -Ptests -Ptests-CI -Pjmh". Doing > another run failed at the integration-tests module due to the RAT check > erroring on some files. > These files were left behind within the source tree while running the > integration tests, grouped under a parent subdirectory of: > "tests/integration-tests/null". > It seems it is from at least 2 different tests, with subdirs for > "bindings0-L", "journal0-L" and "large-msg0-L" showing up first over an hour > into a run, and then further "bindings", "journal" and "large-msg" subdirs > showing up after another hour or so. > Its unclear which tests are leaving them behind. Perhaps someone more > familiar with the tests could have ideas where to look for such paths being > constructed etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQNET-718) Inflight messages are not cancelled after timeout
[ https://issues.apache.org/jira/browse/AMQNET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved AMQNET-718. --- Fix Version/s: AMQP-1.8.2 AMQP-2.0.0 Resolution: Fixed > Inflight messages are not cancelled after timeout > - > > Key: AMQNET-718 > URL: https://issues.apache.org/jira/browse/AMQNET-718 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP, NMS >Affects Versions: AMQP-1.8.1, AMQP-2.0.0 >Reporter: Krzysztof Porębski >Priority: Major > Fix For: AMQP-2.0.0, AMQP-1.8.2 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Inflight messages are not cancelled in case of timeout. It may results in > duplicates, when library used with producer control flow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3479) Upgrade Apache Directory Server version to 2.0.0.AM26
[ https://issues.apache.org/jira/browse/ARTEMIS-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415023#comment-17415023 ] Robbie Gemmell commented on ARTEMIS-3479: - AM26 breaks some tests on Java 16+17, which is why it was downgraded back to AM25 when it was last updated to AM26 > Upgrade Apache Directory Server version to 2.0.0.AM26 > - > > Key: ARTEMIS-3479 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3479 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-3479) Upgrade Apache Directory Server version to 2.0.0.AM26
[ https://issues.apache.org/jira/browse/ARTEMIS-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415023#comment-17415023 ] Robbie Gemmell edited comment on ARTEMIS-3479 at 9/14/21, 4:09 PM: --- AM26 breaks some tests on Java 16+17, which is why it was downgraded back to AM25 when it was last updated to AM26 https://github.com/apache/activemq-artemis/commit/2e2cd1f0732392ae4df8d538611e5a5aa18dd10c was (Author: gemmellr): AM26 breaks some tests on Java 16+17, which is why it was downgraded back to AM25 when it was last updated to AM26 > Upgrade Apache Directory Server version to 2.0.0.AM26 > - > > Key: ARTEMIS-3479 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3479 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3475) Possible recursion on PacketImpl::toString
[ https://issues.apache.org/jira/browse/ARTEMIS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-3475: - > Possible recursion on PacketImpl::toString > -- > > Key: ARTEMIS-3475 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3475 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > This is a mix of a bug and a task... > classes extending Packet on core client are using a method named > getParentString() on the toString(); > The initial intent was to be simple and never to abuse inheritance on the > getParentString(); > Recent iteration on the code added a few occasions with toString() calling > getParentString() calling toString() what caused a recursive loop. > I'm making this simpler. by introducing a getPacketString() on PacketImpl > where every extension of PacketImpl to simply call super.getParentString(); > Even though it still possible for someone to call itself on > getParentString(), at least it would be clearer and easier to catch on > revisions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3475) Possible recursion on PacketImpl::toString
[ https://issues.apache.org/jira/browse/ARTEMIS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-3475. --- Resolution: Fixed > Possible recursion on PacketImpl::toString > -- > > Key: ARTEMIS-3475 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3475 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.19.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a mix of a bug and a task... > classes extending Packet on core client are using a method named > getParentString() on the toString(); > The initial intent was to be simple and never to abuse inheritance on the > getParentString(); > Recent iteration on the code added a few occasions with toString() calling > getParentString() calling toString() what caused a recursive loop. > I'm making this simpler. by introducing a getPacketString() on PacketImpl > where every extension of PacketImpl to simply call super.getParentString(); > Even though it still possible for someone to call itself on > getParentString(), at least it would be clearer and easier to catch on > revisions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3475) Possible recursion on PacketImpl::toString
[ https://issues.apache.org/jira/browse/ARTEMIS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-3475: Fix Version/s: 2.19.0 > Possible recursion on PacketImpl::toString > -- > > Key: ARTEMIS-3475 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3475 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.19.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a mix of a bug and a task... > classes extending Packet on core client are using a method named > getParentString() on the toString(); > The initial intent was to be simple and never to abuse inheritance on the > getParentString(); > Recent iteration on the code added a few occasions with toString() calling > getParentString() calling toString() what caused a recursive loop. > I'm making this simpler. by introducing a getPacketString() on PacketImpl > where every extension of PacketImpl to simply call super.getParentString(); > Even though it still possible for someone to call itself on > getParentString(), at least it would be clearer and easier to catch on > revisions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AMQ-8386) Broken links in documentation website Overview page: ActiveMQ Release
[ https://issues.apache.org/jira/browse/AMQ-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved AMQ-8386. - Resolution: Fixed These were probably broken since I removed the ancient < 5.x release entries in [https://github.com/apache/activemq-website/commit/74d732bade7627626395c0e15057cbec4cdd0314] (as the pages were largely useless anyway due to broken links etc and most of them were for stuff that pre-dates the Apache ActiveMQ project being established anyway). The page clearly isnt well trodden, it hasnt been updated in years, and the docs link on it is also broken too. Given its so stale, and the release content is already much better handled elsewere, I've just removed most of the content but made sure the remaining 2 links work. The page itself should probably just go away with some further cleanup. > Broken links in documentation website Overview page: ActiveMQ Release > - > > Key: AMQ-8386 > URL: https://issues.apache.org/jira/browse/AMQ-8386 > Project: ActiveMQ > Issue Type: Bug >Reporter: Charlie Chen >Priority: Minor > > We’ve identified the following broken URLs on the Apache ActiveMQ “Classic” > documentation website Overview Page: [ActiveMQ > (apache.org)|https://activemq.apache.org/overview] > * [ActiveMQ 1.1 Release|https://activemq.apache.org/activemq-11-release] > * [ActiveMQ 1.2 Release|https://activemq.apache.org/activemq-12-release] > * [ActiveMQ 1.3 Release|https://activemq.apache.org/activemq-13-release] > * [ActiveMQ 1.4 Release|https://activemq.apache.org/activemq-14-release] > * [ActiveMQ 1.5 Release|https://activemq.apache.org/activemq-15-release] > * [ActiveMQ 2.0 Release|https://activemq.apache.org/activemq-20-release] > * [ActiveMQ 2.1 Release|https://activemq.apache.org/activemq-21-release] > * [ActiveMQ 3.0 Release|https://activemq.apache.org/activemq-30-release] > * [ActiveMQ 3.1 Release|https://activemq.apache.org/activemq-31-release] > * [ActiveMQ 3.2.1 Release|https://activemq.apache.org/activemq-321-release] > * [ActiveMQ 3.2.2 Release|https://activemq.apache.org/activemq-322-release] > * [ActiveMQ 3.2 Release|https://activemq.apache.org/activemq-32-release] > * [ActiveMQ 4.0.1 Release|https://activemq.apache.org/activemq-401-release] > * [ActiveMQ 4.0.2 Release|https://activemq.apache.org/activemq-402-release] > * [ActiveMQ 4.0 M4 > Release|https://activemq.apache.org/activemq-40-m4-release] > * [ActiveMQ 4.0 RC2 > Release|https://activemq.apache.org/activemq-40-rc2-release] > * [ActiveMQ 4.0 Release|https://activemq.apache.org/activemq-40-release] > * [ActiveMQ 4.1.0 Release|https://activemq.apache.org/activemq-410-release] > * [ActiveMQ 4.1.1 Release|https://activemq.apache.org/activemq-411-release] > * [ActiveMQ 4.1.2 Release|https://activemq.apache.org/activemq-412-release] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416163#comment-17416163
]
Robbie Gemmell commented on ARTEMIS-3486:
-
Not something I have used, buttry creating a broker instance first (see
./bin/artemis help create) and then using the subsequent instance-specific
artemis command created for it.
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Priority: Major
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416162#comment-17416162
]
Robbie Gemmell commented on ARTEMIS-3486:
-
Not something I have used, buttry creating a broker instance first (see
./bin/artemis help create) and then using the subsequent instance-specific
artemis command created for it.
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Priority: Major
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3486:
Comment: was deleted
(was: Not something I have used, buttry creating a broker instance first
(see ./bin/artemis help create) and then using the subsequent instance-specific
artemis command created for it.)
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Priority: Major
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416193#comment-17416193
]
Robbie Gemmell commented on ARTEMIS-3486:
-
It isnt really at all clear from the docs that is the case, especially given
"artemis data' does exist on the 'non-instance' command too, so it could
probably be improved.
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Priority: Major
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-3486:
-
Assignee: Robbie Gemmell
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Assignee: Robbie Gemmell
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3486:
Priority: Minor (was: Major)
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Assignee: Robbie Gemmell
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3486) refresh data tools documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3486:
Summary: refresh data tools documentation (was: artemis data exp
subcommand uknown)
> refresh data tools documentation
>
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Assignee: Robbie Gemmell
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CLI data tools documentation doesnt notice it is discussing the
> broker-instance related commands. The examples output and options shown are
> also stale and missing many recent additions, it should be updated.
>
>
> == Original Description =
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> [https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html]
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3486) artemis data exp subcommand uknown
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3486:
Description:
The CLI data tools documentation doesnt notice it is discussing the
broker-instance related commands. The examples output and options shown are
also stale and missing many recent additions, it should be updated.
== Original Description =
Steps to reproduce:
# Download the latest apache artemis binary and unarchive
# Run
{noformat}
./bin/artemis data exp
{noformat}
Expected results, according to
[https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html]
:
# the _exp_ subcommand should be known
Actual results:
# the command fails with
{noformat}
Found unexpected parameters: [exp]
{noformat}
Running
{noformat}
./bin/artemis help data
{noformat}
outputs
{noformat}
NAME
artemis data - data tools group (print) (example ./artemis data print)
SYNOPSIS
artemis data
artemis data print ...
artemis data recover ...
COMMANDS
...
{noformat}
was:
Steps to reproduce:
# Download the latest apache artemis binary and unarchive
# Run
{noformat}
./bin/artemis data exp
{noformat}
Expected results, according to
https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html
:
# the _exp_ subcommand should be known
Actual results:
# the command fails with
{noformat}
Found unexpected parameters: [exp]
{noformat}
Running
{noformat}
./bin/artemis help data
{noformat}
outputs
{noformat}
NAME
artemis data - data tools group (print) (example ./artemis data print)
SYNOPSIS
artemis data
artemis data print ...
artemis data recover ...
COMMANDS
...
{noformat}
> artemis data exp subcommand uknown
> --
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Assignee: Robbie Gemmell
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CLI data tools documentation doesnt notice it is discussing the
> broker-instance related commands. The examples output and options shown are
> also stale and missing many recent additions, it should be updated.
>
>
> == Original Description =
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> [https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html]
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3486) refresh data tools documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3486:
Issue Type: Task (was: Bug)
> refresh data tools documentation
>
>
> Key: ARTEMIS-3486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3486
> Project: ActiveMQ Artemis
> Issue Type: Task
>Affects Versions: 2.18.0
> Environment: Mac OS 10.15.7
>Reporter: Sebastian-Ion TINCU
>Assignee: Robbie Gemmell
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CLI data tools documentation doesnt notice it is discussing the
> broker-instance related commands. The examples output and options shown are
> also stale and missing many recent additions, it should be updated.
>
>
> == Original Description =
> Steps to reproduce:
> # Download the latest apache artemis binary and unarchive
> # Run
> {noformat}
> ./bin/artemis data exp
> {noformat}
> Expected results, according to
> [https://activemq.apache.org/components/artemis/documentation/latest/data-tools.html]
> :
> # the _exp_ subcommand should be known
> Actual results:
> # the command fails with
> {noformat}
> Found unexpected parameters: [exp]
> {noformat}
> Running
> {noformat}
> ./bin/artemis help data
> {noformat}
> outputs
> {noformat}
> NAME
> artemis data - data tools group (print) (example ./artemis data print)
> SYNOPSIS
> artemis data
> artemis data print ...
> artemis data recover ...
> COMMANDS
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
