[jira] [Work logged] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?focusedWorklogId=894412=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894412 ] ASF GitHub Bot logged work on ARTEMIS-4528: --- Author: ASF GitHub Bot Created on: 06/Dec/23 22:57 Start Date: 06/Dec/23 22:57 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #4706: URL: https://github.com/apache/activemq-artemis/pull/4706#discussion_r1417743646 ## artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java: ## @@ -472,6 +474,8 @@ public ActiveMQServerImpl(Configuration configuration, ConfigurationUtils.validateConfiguration(configuration); } + Security.addProvider(new PemKeyStoreProvider()); Review Comment: Ick. Should this be static like the call itself, or otherwise gated, to avoid doing it repeatedly given it can only succeed once? Checking the return to see whether it wasnt installed if it already was and maybe log it didnt add? Also, this functionality is essentially broker-only unless you happen to coincidentally be in the same JVM after it starts? The test or docs (which apply to the client too) dont make that clear. ## tests/security-resources/build.sh: ## @@ -153,6 +153,10 @@ keytool -storetype pkcs12 -keystore unknown-client-keystore.p12 -storepass $STOR keytool -importkeystore -srckeystore unknown-client-keystore.p12 -destkeystore unknown-client-keystore.jceks -srcstoretype pkcs12 -deststoretype jceks -srcstorepass securepass -deststorepass securepass keytool -importkeystore -srckeystore unknown-client-keystore.p12 -destkeystore unknown-client-keystore.jks -srcstoretype pkcs12 -deststoretype jks -srcstorepass securepass -deststorepass securepass +# PEM versions +openssl pkcs12 -in server-keystore.p12 -out server-key-cert.pem -nodes -password pass:$STORE_PASS +openssl pkcs12 -in client-keystore.p12 -out client-key-cert.pem -nodes -password pass:$STORE_PASS + # Clean up working files # --- -rm -f *.crt *.csr openssl-* +rm -f *.csr openssl-* Review Comment: This adds/leaves a bunch of intermediate files that we dont use, and so always deleted previously. Avoidable? ## tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/ssl/SslPEMTest.java: ## @@ -0,0 +1,134 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.activemq.artemis.tests.integration.ssl; + +import java.lang.management.ManagementFactory; +import java.net.URL; +import java.util.HashMap; +import java.util.HashSet; +import java.util.Map; +import java.util.Set; + +import org.apache.activemq.artemis.api.core.Message; +import org.apache.activemq.artemis.api.core.QueueConfiguration; +import org.apache.activemq.artemis.api.core.SimpleString; +import org.apache.activemq.artemis.api.core.TransportConfiguration; +import org.apache.activemq.artemis.api.core.client.ActiveMQClient; +import org.apache.activemq.artemis.api.core.client.ClientConsumer; +import org.apache.activemq.artemis.api.core.client.ClientMessage; +import org.apache.activemq.artemis.api.core.client.ClientProducer; +import org.apache.activemq.artemis.api.core.client.ClientSession; +import org.apache.activemq.artemis.api.core.client.ClientSessionFactory; +import org.apache.activemq.artemis.api.core.client.ServerLocator; +import org.apache.activemq.artemis.core.config.impl.ConfigurationImpl; +import org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants; +import org.apache.activemq.artemis.core.security.Role; +import org.apache.activemq.artemis.core.server.ActiveMQServer; +import org.apache.activemq.artemis.core.server.ActiveMQServers; +import org.apache.activemq.artemis.core.settings.HierarchicalRepository; +import org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager; +import org.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManager; +import org.apache.activemq.artemis.tests.integration.security.SecurityTest; +import
[jira] [Work logged] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?focusedWorklogId=894413=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894413 ] ASF GitHub Bot logged work on ARTEMIS-4528: --- Author: ASF GitHub Bot Created on: 06/Dec/23 22:57 Start Date: 06/Dec/23 22:57 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #4706: URL: https://github.com/apache/activemq-artemis/pull/4706#discussion_r1417743646 ## artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java: ## @@ -472,6 +474,8 @@ public ActiveMQServerImpl(Configuration configuration, ConfigurationUtils.validateConfiguration(configuration); } + Security.addProvider(new PemKeyStoreProvider()); Review Comment: Ick. Should this be static like the call itself, or otherwise gated, to avoid doing it repeatedly given it can only succeed once? Checking the return to see whether it wasnt installed if it already was and maybe [trace] log it didnt add? Also, this functionality is essentially broker-only unless you happen to coincidentally be in the same JVM after it starts? The test or docs (which apply to the client too) dont make that clear. Issue Time Tracking --- Worklog Id: (was: 894413) Time Spent: 50m (was: 40m) > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 50m > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?focusedWorklogId=894402=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894402 ] ASF GitHub Bot logged work on OPENWIRE-69: -- Author: ASF GitHub Bot Created on: 06/Dec/23 22:36 Start Date: 06/Dec/23 22:36 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4: URL: https://github.com/apache/activemq-openwire/pull/4#issuecomment-1843799041 The change makes sense to me, will review tomorrow if you push more updates. It's likely there's more areas where deeper validation would be useful to prevent user error when updating / adding to openwire commands. Issue Time Tracking --- Worklog Id: (was: 894402) Time Spent: 0.5h (was: 20m) > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4527) Redistributor race when consumerCount reaches 0 in cluster
[
https://issues.apache.org/jira/browse/ARTEMIS-4527?focusedWorklogId=894400=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894400
]
ASF GitHub Bot logged work on ARTEMIS-4527:
---
Author: ASF GitHub Bot
Created on: 06/Dec/23 22:34
Start Date: 06/Dec/23 22:34
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4705:
URL:
https://github.com/apache/activemq-artemis/pull/4705#issuecomment-1843796881
Checkstyle violations:
```
[INFO] There are 5 errors reported by Checkstyle 10.11.0 with
/home/runner/work/activemq-artemis/activemq-artemis/tests/integration-tests/../../etc/checkstyle.xml
ruleset.
Error:
src/test/java/org/apache/activemq/artemis/tests/integration/cluster/distribution/UnsynchronizedClusterReproducer.java:[123,49]
(whitespace) WhitespaceAround: '{' is not followed by whitespace.
Error:
src/test/java/org/apache/activemq/artemis/tests/integration/cluster/distribution/UnsynchronizedClusterReproducer.java:[137,77]
(whitespace) WhitespaceAround: '{' is not followed by whitespace.
Error:
src/test/java/org/apache/activemq/artemis/tests/integration/cluster/distribution/UnsynchronizedClusterReproducer.java:[153,40]
(whitespace) WhitespaceAround: '{' is not followed by whitespace.
Error:
src/test/java/org/apache/activemq/artemis/tests/integration/cluster/distribution/UnsynchronizedClusterReproducer.java:[223,37]
(whitespace) WhitespaceAround: '{' is not followed by whitespace.
Error:
src/test/java/org/apache/activemq/artemis/tests/integration/cluster/distribution/UnsynchronizedClusterReproducer.java:[235,37]
(whitespace) WhitespaceAround: '{' is not followed by whitespace.
```
Issue Time Tracking
---
Worklog Id: (was: 894400)
Time Spent: 20m (was: 10m)
> Redistributor race when consumerCount reaches 0 in cluster
> --
>
> Key: ARTEMIS-4527
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4527
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a very rare bug caused by cluster notifications arriving in the wrong
> order in some very specific circumstances
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?focusedWorklogId=894399=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894399 ] ASF GitHub Bot logged work on ARTEMIS-4528: --- Author: ASF GitHub Bot Created on: 06/Dec/23 22:34 Start Date: 06/Dec/23 22:34 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4706: URL: https://github.com/apache/activemq-artemis/pull/4706#issuecomment-1843796721 > This looks great overall, but I have one question. Why did so many (seemingly) unrelated SSL resources change (e.g. keystores, truststores, etc.)? My guess was the changes in the security resources 'build.sh' to create the needed certs resulted in a rerun of the script which updated all the certificates it creates. Issue Time Tracking --- Worklog Id: (was: 894399) Time Spent: 0.5h (was: 20m) > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?focusedWorklogId=894398=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894398 ] ASF GitHub Bot logged work on ARTEMIS-4528: --- Author: ASF GitHub Bot Created on: 06/Dec/23 22:30 Start Date: 06/Dec/23 22:30 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4706: URL: https://github.com/apache/activemq-artemis/pull/4706#issuecomment-1843792664 This looks great overall, but I have one question. Why did so many (seemingly) unrelated SSL resource change (e.g. keystore, truststores, etc.)? Issue Time Tracking --- Worklog Id: (was: 894398) Time Spent: 20m (was: 10m) > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 20m > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4530) Clean up SessionCallback interface
[
https://issues.apache.org/jira/browse/ARTEMIS-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4530:
Description: Now that the soft/weak reference caches related to paging are
gone we can clean up the
{{org.apache.activemq.artemis.spi.core.protocol.SessionCallback}} interface
since we no longer need direct references to the message.
> Clean up SessionCallback interface
> --
>
> Key: ARTEMIS-4530
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4530
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> Now that the soft/weak reference caches related to paging are gone we can
> clean up the
> {{org.apache.activemq.artemis.spi.core.protocol.SessionCallback}} interface
> since we no longer need direct references to the message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4530) Clean up SessionCallback interface
Justin Bertram created ARTEMIS-4530: --- Summary: Clean up SessionCallback interface Key: ARTEMIS-4530 URL: https://issues.apache.org/jira/browse/ARTEMIS-4530 Project: ActiveMQ Artemis Issue Type: Task Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?focusedWorklogId=894388=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894388 ] ASF GitHub Bot logged work on OPENWIRE-69: -- Author: ASF GitHub Bot Created on: 06/Dec/23 21:44 Start Date: 06/Dec/23 21:44 Worklog Time Spent: 10m Work Description: cshannon commented on PR #4: URL: https://github.com/apache/activemq-openwire/pull/4#issuecomment-1843739420 So I am going to mark this as a draft for now as it works but I think I will update this to be smarter. Right now it just looks for unique sequences which is a good start but I think we should be smarter and just iterate over it after we have sorted the list and also verify that there are no gaps. We wouldn't want sequence ids of something like 1,2,4 we would only want to allow 1,2,3 so I can fix that tomorrow and push a new commit. Issue Time Tracking --- Worklog Id: (was: 894388) Time Spent: 20m (was: 10m) > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?focusedWorklogId=894386=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894386 ] ASF GitHub Bot logged work on OPENWIRE-69: -- Author: ASF GitHub Bot Created on: 06/Dec/23 21:39 Start Date: 06/Dec/23 21:39 Worklog Time Spent: 10m Work Description: cshannon opened a new pull request, #4: URL: https://github.com/apache/activemq-openwire/pull/4 PartialCommand and ProducerAck duplicate the same sequence id on more than one property. This commit fixes the sequence and also adds validation to the marshaller to verify that sequences are not duplicated and if they are an IllegalArgumentException is thrown. Issue Time Tracking --- Worklog Id: (was: 894386) Remaining Estimate: 0h Time Spent: 10m > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4529) NPE with empty core message and STOMP consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4529?focusedWorklogId=894384=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894384 ] ASF GitHub Bot logged work on ARTEMIS-4529: --- Author: ASF GitHub Bot Created on: 06/Dec/23 21:35 Start Date: 06/Dec/23 21:35 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4707: URL: https://github.com/apache/activemq-artemis/pull/4707 (no comment) Issue Time Tracking --- Worklog Id: (was: 894384) Remaining Estimate: 0h Time Spent: 10m > NPE with empty core message and STOMP consumer > -- > > Key: ARTEMIS-4529 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4529 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4529) NPE with empty core message and STOMP consumer
Justin Bertram created ARTEMIS-4529: --- Summary: NPE with empty core message and STOMP consumer Key: ARTEMIS-4529 URL: https://issues.apache.org/jira/browse/ARTEMIS-4529 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?focusedWorklogId=894380=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894380 ] ASF GitHub Bot logged work on OPENWIRE-66: -- Author: ASF GitHub Bot Created on: 06/Dec/23 21:20 Start Date: 06/Dec/23 21:20 Worklog Time Spent: 10m Work Description: cshannon commented on PR #3: URL: https://github.com/apache/activemq-openwire/pull/3#issuecomment-1843708341 Going ahead and merging this so I can continue on with other PRs, if anything needs to be changed we can do follow on PRs Issue Time Tracking --- Worklog Id: (was: 894380) Time Spent: 0.5h (was: 20m) > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?focusedWorklogId=894379=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894379 ] ASF GitHub Bot logged work on OPENWIRE-66: -- Author: ASF GitHub Bot Created on: 06/Dec/23 21:19 Start Date: 06/Dec/23 21:19 Worklog Time Spent: 10m Work Description: cshannon merged PR #3: URL: https://github.com/apache/activemq-openwire/pull/3 Issue Time Tracking --- Worklog Id: (was: 894379) Time Spent: 20m (was: 10m) > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793937#comment-17793937 ] ASF subversion and git services commented on OPENWIRE-66: - Commit 22a33eefc19e6c0403bb6530172a8bb9772e649d in activemq-openwire's branch refs/heads/main from Christopher L. Shannon [ https://gitbox.apache.org/repos/asf?p=activemq-openwire.git;h=22a33ee ] OPENWIRE-66 - Bring project build up to date (#3) This brings the build up to date by upgrading maven plugins, dependences and to JDK 17. It also updates to ActiveMQ 6.0.1 for testing and jakarta. This comimt is just for the build itself and future updates will add the latest versions of OpenWire. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (AMQ-9412) ActiveMQ Docker Image doesn't start
Eddú Meléndez created AMQ-9412:
--
Summary: ActiveMQ Docker Image doesn't start
Key: AMQ-9412
URL: https://issues.apache.org/jira/browse/AMQ-9412
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.17.6, 5.18.3, 6.0.0
Reporter: Eddú Meléndez
Running *docker run -eACTIVEMQ_CONNECTION_USER=tc
-eACTIVEMQ_CONNECTION_PASSWORD=tc apache/activemq-classic:5.17.6* fails with
{noformat}
Enabling ActiveMQ Connection Security
/usr/local/bin/entrypoint.sh: 29: read: Illegal option -d
/usr/local/bin/entrypoint.sh: 39: Bad substitution{noformat}
Also, are images for platform linux/amd64 going to be provided?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
[ https://issues.apache.org/jira/browse/OPENWIRE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated OPENWIRE-69: Description: PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should be fixed, and maybe checked by the annotation processor since no two properties should have the same sequence. (was: PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should fixed, and maybe checked by the annotation processor since no two properties should have the same sequence.) > Sequence ID for openwire properties is not correct in some types > > > Key: OPENWIRE-69 > URL: https://issues.apache.org/jira/browse/OPENWIRE-69 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Timothy A. Bish >Assignee: Christopher L. Shannon >Priority: Major > > PartialCommand and ProducerAck seem to have identical sequence ID values for > the property annotations which should be fixed, and maybe checked by the > annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-69) Sequence ID for openwire properties is not correct in some types
Timothy A. Bish created OPENWIRE-69: --- Summary: Sequence ID for openwire properties is not correct in some types Key: OPENWIRE-69 URL: https://issues.apache.org/jira/browse/OPENWIRE-69 Project: ActiveMQ OpenWire Issue Type: Bug Reporter: Timothy A. Bish Assignee: Christopher L. Shannon PartialCommand and ProducerAck seem to have identical sequence ID values for the property annotations which should fixed, and maybe checked by the annotation processor since no two properties should have the same sequence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4521) Deleting divert using management API doesn't remove binding from journal
[
https://issues.apache.org/jira/browse/ARTEMIS-4521?focusedWorklogId=894345=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894345
]
ASF GitHub Bot logged work on ARTEMIS-4521:
---
Author: ASF GitHub Bot
Created on: 06/Dec/23 16:45
Start Date: 06/Dec/23 16:45
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4697:
URL:
https://github.com/apache/activemq-artemis/pull/4697#issuecomment-1843272830
@AntonRoskvist, you're absolutely correct. Nice catch! I've updated the code
to adjust for this.
@erwindon, by the way, I think this may be related to an issue you've see
with retroactive address and diverts not getting cleaned up properly.
Issue Time Tracking
---
Worklog Id: (was: 894345)
Time Spent: 1h 10m (was: 1h)
> Deleting divert using management API doesn't remove binding from journal
>
>
> Key: ARTEMIS-4521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4521
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> After a JMX {{createDivert}} followed by a JMX {{destroyDivert}} followed by
> a broker restart the divert is visible again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OPENWIRE-46) Consider archiving this project/repo
[
https://issues.apache.org/jira/browse/OPENWIRE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon closed OPENWIRE-46.
--
Resolution: Won't Do
This project is planned to be revived and will be used for new Openwire versions
> Consider archiving this project/repo
>
>
> Key: OPENWIRE-46
> URL: https://issues.apache.org/jira/browse/OPENWIRE-46
> Project: ActiveMQ OpenWire
> Issue Type: Task
>Reporter: Lucas Tétreault
>Priority: Minor
>
> {color:#00}Neither Active Classic nor Artemis appear to use this. Should
> this repo be archived to avoid confusion and drift?
> {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-67: --- Priority: Blocker (was: Critical) > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Priority: Blocker > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-68) Import all updated OpenWire versions that have Throwable CVE fix
Christopher L. Shannon created OPENWIRE-68: -- Summary: Import all updated OpenWire versions that have Throwable CVE fix Key: OPENWIRE-68 URL: https://issues.apache.org/jira/browse/OPENWIRE-68 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Need to update all the legacy versions to make sure the CVE for throwable validation is fixed. Openwire is up to version 12 so all versions should be imported and the tests as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
Christopher L. Shannon created OPENWIRE-67: -- Summary: Update generator to fix Throwable type validation CVE Key: OPENWIRE-67 URL: https://issues.apache.org/jira/browse/OPENWIRE-67 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Fix For: 1.0.0 Need to make sure to update the generator to include the fix from https://issues.apache.org/jira/browse/AMQ-9370 to prevent https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-67) Update generator to fix Throwable type validation CVE
[ https://issues.apache.org/jira/browse/OPENWIRE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-67: --- Issue Type: Bug (was: Task) > Update generator to fix Throwable type validation CVE > - > > Key: OPENWIRE-67 > URL: https://issues.apache.org/jira/browse/OPENWIRE-67 > Project: ActiveMQ OpenWire > Issue Type: Bug >Reporter: Christopher L. Shannon >Priority: Critical > Fix For: 1.0.0 > > > Need to make sure to update the generator to include the fix from > https://issues.apache.org/jira/browse/AMQ-9370 to prevent > https://nvd.nist.gov/vuln/detail/CVE-2023-46604 from coming back in newly > generated versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?focusedWorklogId=894329=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894329 ] ASF GitHub Bot logged work on ARTEMIS-4528: --- Author: ASF GitHub Bot Created on: 06/Dec/23 15:42 Start Date: 06/Dec/23 15:42 Worklog Time Spent: 10m Work Description: gtully opened a new pull request, #4706: URL: https://github.com/apache/activemq-artemis/pull/4706 (no comment) Issue Time Tracking --- Worklog Id: (was: 894329) Remaining Estimate: 0h Time Spent: 10m > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 10m > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4528) TLS support PEM format for key and trust store type
Gary Tully created ARTEMIS-4528: --- Summary: TLS support PEM format for key and trust store type Key: ARTEMIS-4528 URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 Project: ActiveMQ Artemis Issue Type: Improvement Components: Configuration Affects Versions: 2.31.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.32.0 managing key and trust store passwords when the credentials are securely stored or managed by other means is a nuisance. there is a nice PEM keystore provider at: [https://github.com/ctron/pem-keystore] This gives us an intuitive way to easily reference a simple cert or key without a password as is the case with jsk or pkcs12 tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AMQNET-836) UnobservedTaskException after a failover
[
https://issues.apache.org/jira/browse/AMQNET-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Borisov updated AMQNET-836:
-
Summary: UnobservedTaskException after a failover (was:
UnobservedTaskException in the failover)
> UnobservedTaskException after a failover
>
>
> Key: AMQNET-836
> URL: https://issues.apache.org/jira/browse/AMQNET-836
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
> Environment: .NET 6
>Reporter: Pavel Borisov
>Priority: Major
>
> When the ActiveMQ instance becomes inaccessible, and the failover happens,
> our applications start to report the following error:
> _A Task's exception(s) were not observed either by Waiting on the Task or
> accessing its Exception property. As a result, the unobserved exception was
> rethrown by the finalizer thread._
> The actual unobserved error is a SocketException.
> The origin of the issue is in
> {*}TcpTransportFactory.{*}{*}TryConnectSocket{*}
> ([github|https://github.com/apache/activemq-nms-openwire/blob/b89b7498d12fe2f68ee5ee248bb2168c62ceaf3a/src/Transport/Tcp/TcpTransportFactory.cs#L240]).
> It starts an async task (socket.BeginConnect), but its result is not
> observed. The result is checked by the `socket.Connected` only, and in case
> of failure, the actual exception in the task stays unobserved and is
> eventually promoted to the UnobservedTaskException event.
> Also, for APM methods (Begin*), there are End* methods that *must* be called
> according to the docs. But the call to EndConnect is missing in
> {*}TryConnectSocket{*}, so a socket stays partially invalid after a
> successful connection.
> The [snippet
> here|https://gist.github.com/Inok/9b17282532bca8a01cc5fc0ab9872433] contains
> the same code with some logging, and it reproduces the issue (.NET 6, run in
> Release mode).
> The fix for both problems is probably [something like
> this|https://gist.github.com/Inok/666d647b1bb337bcbef8cad02032237f].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (AMQNET-836) UnobservedTaskException in the failover
Pavel Borisov created AMQNET-836:
Summary: UnobservedTaskException in the failover
Key: AMQNET-836
URL: https://issues.apache.org/jira/browse/AMQNET-836
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Environment: .NET 6
Reporter: Pavel Borisov
When the ActiveMQ becomes inaccessible, and the failover happens, our
applications start to report the following error:
_A Task's exception(s) were not observed either by Waiting on the Task or
accessing its Exception property. As a result, the unobserved exception was
rethrown by the finalizer thread._
The actual unobserved error is a SocketException.
The origin of the issue is in {*}TcpTransportFactory.{*}{*}TryConnectSocket{*}
([github|https://github.com/apache/activemq-nms-openwire/blob/b89b7498d12fe2f68ee5ee248bb2168c62ceaf3a/src/Transport/Tcp/TcpTransportFactory.cs#L240]).
It starts an async task (socket.BeginConnect), but its result is not observed.
The result is checked by the `socket.Connected` only, and in case of failure,
the actual exception in the task stays unobserved and is eventually promoted to
the UnobservedTaskException event.
Also, for APM methods (Begin*), there are End* methods that *must* be called
according to the docs. But the call to EndConnect is missing in
{*}TryConnectSocket{*}, so a socket stays partially invalid after a successful
connection.
The [snippet
here|https://gist.github.com/Inok/9b17282532bca8a01cc5fc0ab9872433] contains
the same code with some logging, and it reproduces the issue (.NET 6, run in
Release mode).
The fix for both problems is probably [something like
this|https://gist.github.com/Inok/666d647b1bb337bcbef8cad02032237f].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AMQNET-836) UnobservedTaskException in the failover
[
https://issues.apache.org/jira/browse/AMQNET-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Borisov updated AMQNET-836:
-
Description:
When the ActiveMQ instance becomes inaccessible, and the failover happens, our
applications start to report the following error:
_A Task's exception(s) were not observed either by Waiting on the Task or
accessing its Exception property. As a result, the unobserved exception was
rethrown by the finalizer thread._
The actual unobserved error is a SocketException.
The origin of the issue is in {*}TcpTransportFactory.{*}{*}TryConnectSocket{*}
([github|https://github.com/apache/activemq-nms-openwire/blob/b89b7498d12fe2f68ee5ee248bb2168c62ceaf3a/src/Transport/Tcp/TcpTransportFactory.cs#L240]).
It starts an async task (socket.BeginConnect), but its result is not observed.
The result is checked by the `socket.Connected` only, and in case of failure,
the actual exception in the task stays unobserved and is eventually promoted to
the UnobservedTaskException event.
Also, for APM methods (Begin*), there are End* methods that *must* be called
according to the docs. But the call to EndConnect is missing in
{*}TryConnectSocket{*}, so a socket stays partially invalid after a successful
connection.
The [snippet
here|https://gist.github.com/Inok/9b17282532bca8a01cc5fc0ab9872433] contains
the same code with some logging, and it reproduces the issue (.NET 6, run in
Release mode).
The fix for both problems is probably [something like
this|https://gist.github.com/Inok/666d647b1bb337bcbef8cad02032237f].
was:
When the ActiveMQ becomes inaccessible, and the failover happens, our
applications start to report the following error:
_A Task's exception(s) were not observed either by Waiting on the Task or
accessing its Exception property. As a result, the unobserved exception was
rethrown by the finalizer thread._
The actual unobserved error is a SocketException.
The origin of the issue is in {*}TcpTransportFactory.{*}{*}TryConnectSocket{*}
([github|https://github.com/apache/activemq-nms-openwire/blob/b89b7498d12fe2f68ee5ee248bb2168c62ceaf3a/src/Transport/Tcp/TcpTransportFactory.cs#L240]).
It starts an async task (socket.BeginConnect), but its result is not observed.
The result is checked by the `socket.Connected` only, and in case of failure,
the actual exception in the task stays unobserved and is eventually promoted to
the UnobservedTaskException event.
Also, for APM methods (Begin*), there are End* methods that *must* be called
according to the docs. But the call to EndConnect is missing in
{*}TryConnectSocket{*}, so a socket stays partially invalid after a successful
connection.
The [snippet
here|https://gist.github.com/Inok/9b17282532bca8a01cc5fc0ab9872433] contains
the same code with some logging, and it reproduces the issue (.NET 6, run in
Release mode).
The fix for both problems is probably [something like
this|https://gist.github.com/Inok/666d647b1bb337bcbef8cad02032237f].
> UnobservedTaskException in the failover
> ---
>
> Key: AMQNET-836
> URL: https://issues.apache.org/jira/browse/AMQNET-836
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
> Environment: .NET 6
>Reporter: Pavel Borisov
>Priority: Major
>
> When the ActiveMQ instance becomes inaccessible, and the failover happens,
> our applications start to report the following error:
> _A Task's exception(s) were not observed either by Waiting on the Task or
> accessing its Exception property. As a result, the unobserved exception was
> rethrown by the finalizer thread._
> The actual unobserved error is a SocketException.
> The origin of the issue is in
> {*}TcpTransportFactory.{*}{*}TryConnectSocket{*}
> ([github|https://github.com/apache/activemq-nms-openwire/blob/b89b7498d12fe2f68ee5ee248bb2168c62ceaf3a/src/Transport/Tcp/TcpTransportFactory.cs#L240]).
> It starts an async task (socket.BeginConnect), but its result is not
> observed. The result is checked by the `socket.Connected` only, and in case
> of failure, the actual exception in the task stays unobserved and is
> eventually promoted to the UnobservedTaskException event.
> Also, for APM methods (Begin*), there are End* methods that *must* be called
> according to the docs. But the call to EndConnect is missing in
> {*}TryConnectSocket{*}, so a socket stays partially invalid after a
> successful connection.
> The [snippet
> here|https://gist.github.com/Inok/9b17282532bca8a01cc5fc0ab9872433] contains
> the same code with some logging, and it reproduces the issue (.NET 6, run in
> Release mode).
> The fix for both problems is probably [something like
> this|https://gist.github.com/Inok/666d647b1bb337bcbef8cad02032237f].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?focusedWorklogId=894310=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894310 ] ASF GitHub Bot logged work on OPENWIRE-66: -- Author: ASF GitHub Bot Created on: 06/Dec/23 14:34 Start Date: 06/Dec/23 14:34 Worklog Time Spent: 10m Work Description: cshannon opened a new pull request, #3: URL: https://github.com/apache/activemq-openwire/pull/3 This brings the build up to date by upgrading maven plugins, dependences and to JDK 17. It also updates to ActiveMQ 6.0.1 for testing and jakarta. This comimt is just for the build itself and future updates will add the latest versions of OpenWire. Issue Time Tracking --- Worklog Id: (was: 894310) Remaining Estimate: 0h Time Spent: 10m > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Upgrade to ActiveMQ 6.0.1 and Jakarta messaging > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. I also noticed there is the openwire-website module that we may just want to remove as it is currently commented out and very out of date. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. > I also noticed there is the openwire-website module that we may just want to > remove as it is currently commented out and very out of date. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Fix Version/s: 1.0.0 > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 1.0.0 > > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OPENWIRE-66 started by Christopher L. Shannon. -- > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Description: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. Things to do: # Update root pom and plugins # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest of the AMQ projects # Update dependencies to latest versions such as mockito, log4j2 etc # Upgrade to JDK 17 *Note:* This task isn't to add the missing OpenWire versions, that is for another issue this is just to fix the build. was: We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. > Things to do: > # Update root pom and plugins > # Change version to 1.0.0-SNAPSHOT instead of 1.0-SNAPSHOT to match the rest > of the AMQ projects > # Update dependencies to latest versions such as mockito, log4j2 etc > # Upgrade to JDK 17 > *Note:* This task isn't to add the missing OpenWire versions, that is for > another issue this is just to fix the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OPENWIRE-66) Bring the Openwire project build up to date
[ https://issues.apache.org/jira/browse/OPENWIRE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated OPENWIRE-66: --- Summary: Bring the Openwire project build up to date (was: Bring the Openwire project up to date) > Bring the Openwire project build up to date > --- > > Key: OPENWIRE-66 > URL: https://issues.apache.org/jira/browse/OPENWIRE-66 > Project: ActiveMQ OpenWire > Issue Type: Task >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > > We will need to be able to generate new Openwire versions going forward to > support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator > no longer works on JDK 11+ due to the removed doclet API that it was relying > on so we need to use this new version going forward which is annotation based. > This project needs to be revived and is quite out of date so this Jira is to > bring the build up to date first before starting to made modifications to > Openwire. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENWIRE-66) Bring the Openwire project up to date
Christopher L. Shannon created OPENWIRE-66: -- Summary: Bring the Openwire project up to date Key: OPENWIRE-66 URL: https://issues.apache.org/jira/browse/OPENWIRE-66 Project: ActiveMQ OpenWire Issue Type: Task Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon We will need to be able to generate new Openwire versions going forward to support things like JMS 2.0 and Jakarta Messaging. The old Openwire generator no longer works on JDK 11+ due to the removed doclet API that it was relying on so we need to use this new version going forward which is annotation based. This project needs to be revived and is quite out of date so this Jira is to bring the build up to date first before starting to made modifications to Openwire. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4527) Redistributor race when consumerCount reaches 0 in cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-4527?focusedWorklogId=894308=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-894308 ] ASF GitHub Bot logged work on ARTEMIS-4527: --- Author: ASF GitHub Bot Created on: 06/Dec/23 14:20 Start Date: 06/Dec/23 14:20 Worklog Time Spent: 10m Work Description: AntonRoskvist opened a new pull request, #4705: URL: https://github.com/apache/activemq-artemis/pull/4705 …ster This is a very rare bug but when triggered, messages in the queue with 0 consumers will have the redistributors loop messages between some or all brokers in a cluster as fast as they can manage, until either some system resource or the clusterBridges producerFlowControl is reached. Will keep happening until consumers are added or cluster bridges are restarted. I don't have a test for this but instead added a reproducer that works with a considerable amount of tweaks. Comments in the reproducer explains how to run it. The reproducer is _not_ a valid or reasonable use case... it builds on some unrelated work I did that accidentally triggered this. I have seen this multiple times in a production environment over the course of several years though, I've just been unable to reproduce it outside of production before accidentally stumbling on it recently. Problem occurs when CONSUMER_CREATED notification arrive before the BINDING_ADDED notification. When that happens the consumerCount for RemoteBinding is incorrect (something like 1-2 lower than actual consumerCount value). Then when consumers disconnect, all are registered properly and RemoteBinding gets a negative consumerCount. The `isHighAcceptPriority` used by the redistributor checks for consumerCount == 0 but since count is now negative it returns as a valid destination. Fix adds synchronization on the postoffice when processing createConsumer so then the previously issued addBinding for sure is done before continuing. I also added double safety in the RemoteQueueBinding by not lowering consumerCount below 0 and also checking for consumerCount <= 0 instead of consumerCount == 0, though neither of these should really be necessary if the cluster notifications always arrive in the correct order. If anyone can figure out a consistent way to trigger this issue I'd be happy to add it. Regardless, if the changes look good otherwise I think the reproducer should be removed rather than merged, leaving it here for verification purposes. One final though is that perhaps all of the sort of create/add/remove operations in the `org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler` should be synchronized? Something building on the current pattern of: `onMessagePacket()` ``` switch fast1: fast1Stuff(); fast2: fast2Stuff(); default: slow() slow: switch slow1: slow1Stuff(); slow2: slow2Stuff(); default: synchronizedStuff() synchronizedStuff: switch ... ... ``` Issue Time Tracking --- Worklog Id: (was: 894308) Remaining Estimate: 0h Time Spent: 10m > Redistributor race when consumerCount reaches 0 in cluster > -- > > Key: ARTEMIS-4527 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4527 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This is a very rare bug caused by cluster notifications arriving in the wrong > order in some very specific circumstances -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4527) Redistributor race when consumerCount reaches 0 in cluster
Anton Roskvist created ARTEMIS-4527: --- Summary: Redistributor race when consumerCount reaches 0 in cluster Key: ARTEMIS-4527 URL: https://issues.apache.org/jira/browse/ARTEMIS-4527 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Anton Roskvist This is a very rare bug caused by cluster notifications arriving in the wrong order in some very specific circumstances -- This message was sent by Atlassian Jira (v8.20.10#820010)
