[jira] [Commented] (ARTEMIS-4017) FQQN Anycast Redistribution on a symmetric cluster is redistributing to different FQQN in the same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735916#comment-17735916
]
João Santos commented on ARTEMIS-4017:
--
[~clebertsuconic] I see the fix has shipped with 2.29.0, I'll update my cluster
and redo the tests in order to confirm that.
I'll get back to this issue with the results once I have them ;)
> FQQN Anycast Redistribution on a symmetric cluster is redistributing to
> different FQQN in the same address
> --
>
> Key: ARTEMIS-4017
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4017
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.25.0
> Environment: The current environment I'm working with is a Symmetric
> cluster of 2 master nodes, and I intend to add a slave node for each of the
> master.
> The first master has the following configuration:
> {code:xml}
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
>
> master0
> true
> data/bindings
> data/journal
> true
> 2
> 10
> 4096
> 10M
>
> data/largemessages
> data/paging
>
>
> tcp://xxx.xxx.xxx.2:61616
> tcp://xxx.xxx.xxx.4:61616
>
>
>
>
> name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true
>
> name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true
>
> name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true
>
>
>
>
> master0
> true
> ON_DEMAND
> 1
>
> master0
> master1
>
>
>
>
>
>
> master0slave0discovery
>
> true
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> DLQ
> ExpiryQueue
> 0
>
> 1000
>
>
> -1
>
> -1
>
> 10
> PAGE
> true
> true
> false
> false
>
>
> ANYCAST
>
> ANYCAST
>
>
>
>
> {code}
> The second master holds the following configuration:
> {code:xml}
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
>
> master1
> true
> data/bindings
> data/journal
> true
> 2
> 10
> 4096
> 10M
>
> data/largemessages
> data/paging
>
>
> tcp://xxx.xxx.xxx.2:61616
> tcp://xxx.xxx.xxx.4:61616
>
>
>
>
> name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true
>
> name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true
>
> name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true
>
>
>
>
> master1
> ON_DEMAND
> 1
>
> master0
> master1
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[ https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866835&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866835 ] ASF GitHub Bot logged work on AMQ-9244: --- Author: ASF GitHub Bot Created on: 21/Jun/23 19:41 Start Date: 21/Jun/23 19:41 Worklog Time Spent: 10m Work Description: jbertram commented on PR #1035: URL: https://github.com/apache/activemq/pull/1035#issuecomment-1601569286 Generally speaking this looks more like a proof-of-concept (i.e. based on [this blog post](https://www.tomitribe.com/blog/jwt-authentication-and-authorization-with-apache-activemq/)) rather than a feature which is ready to use. I'm not sure it makes sense to merge it at this point especially with no tests to validate the functionality and to mitigate future regressions. Issue Time Tracking --- Worklog Id: (was: 866835) Time Spent: 1h 20m (was: 1h 10m) > Add JWT authentication plugin > - > > Key: AMQ-9244 > URL: https://issues.apache.org/jira/browse/AMQ-9244 > Project: ActiveMQ > Issue Type: Task > Components: Security/JAAS >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.19.0, 5.18.2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[
https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866832&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866832
]
ASF GitHub Bot logged work on AMQ-9244:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 19:29
Start Date: 21/Jun/23 19:29
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #1035:
URL: https://github.com/apache/activemq/pull/1035#discussion_r1237586536
##
activemq-broker/src/main/java/org/apache/activemq/security/jwt/JwtAuthenticationBroker.java:
##
@@ -0,0 +1,179 @@
+/**
+ * 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.security.jwt;
+
+import org.apache.activemq.broker.Broker;
+import org.apache.activemq.broker.ConnectionContext;
+import org.apache.activemq.command.ConnectionInfo;
+import org.apache.activemq.jaas.GroupPrincipal;
+import org.apache.activemq.security.AbstractAuthenticationBroker;
+import org.apache.activemq.security.SecurityContext;
+import org.jose4j.jwa.AlgorithmConstraints;
+import org.jose4j.jws.AlgorithmIdentifiers;
+import org.jose4j.jwt.JwtClaims;
+import org.jose4j.jwt.MalformedClaimException;
+import org.jose4j.jwt.consumer.InvalidJwtException;
+import org.jose4j.jwt.consumer.JwtConsumer;
+import org.jose4j.jwt.consumer.JwtConsumerBuilder;
+import org.jose4j.jwt.consumer.JwtContext;
+
+import java.security.Key;
+import java.security.KeyFactory;
+import java.security.NoSuchAlgorithmException;
+import java.security.Principal;
+import java.security.cert.X509Certificate;
+import java.security.spec.InvalidKeySpecException;
+import java.security.spec.X509EncodedKeySpec;
+import java.util.Base64;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+/**
+ * Handle authentication an user based on a JWT token
+ */
+public class JwtAuthenticationBroker extends AbstractAuthenticationBroker {
+
+private final String jwtIssuer;
+private final Claims jwtGroupsClaim;
+private final String jwtValidatingPublicKey;
+
+public JwtAuthenticationBroker(
+final Broker next,
+final String jwtIssuer,
+final Claims jwtGroupsClaim,
+final String jwtValidatingPublicKey) {
+super(next);
+this.jwtIssuer = jwtIssuer;
+this.jwtGroupsClaim = jwtGroupsClaim;
+this.jwtValidatingPublicKey = jwtValidatingPublicKey;
+}
+
+@Override
+public void addConnection(final ConnectionContext context, final
ConnectionInfo info) throws Exception {
+SecurityContext securityContext = context.getSecurityContext();
+if (securityContext == null) {
+securityContext = authenticate(info.getUserName(),
info.getPassword(), null);
+context.setSecurityContext(securityContext);
+securityContexts.add(securityContext);
+}
+
+try {
+super.addConnection(context, info);
+} catch (Exception e) {
+securityContexts.remove(securityContext);
+context.setSecurityContext(null);
+throw e;
+}
+}
+
+@Override
+public SecurityContext authenticate(final String username, final String
password, final X509Certificate[] certificates) throws SecurityException {
+SecurityContext securityContext = null;
+if (!username.isEmpty()) {
+
+// parse the JWT token and check signature, validity, nbf
+try {
+final JwtConsumerBuilder builder = new JwtConsumerBuilder()
+.setRelaxVerificationKeyValidation()
+.setRequireSubject()
+.setSkipDefaultAudienceValidation()
+.setRequireExpirationTime()
+.setExpectedIssuer(jwtIssuer)
+.setAllowedClockSkewInSeconds(5)
+.setVerificationKey(parsePCKS8(jwtValidatingPublicKey))
+.setJwsAlgorithmConstraints(
+new
AlgorithmConstraints(AlgorithmConstraints.C
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[
https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866830&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866830
]
ASF GitHub Bot logged work on AMQ-9244:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 19:25
Start Date: 21/Jun/23 19:25
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #1035:
URL: https://github.com/apache/activemq/pull/1035#discussion_r1237582673
##
activemq-broker/src/main/java/org/apache/activemq/security/jwt/TokenUtils.java:
##
@@ -0,0 +1,157 @@
+/**
+ * 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.security.jwt;
+
+import com.nimbusds.jose.JOSEObjectType;
+import com.nimbusds.jose.JWSHeader;
+import com.nimbusds.jose.crypto.RSASSASigner;
+import com.nimbusds.jose.shaded.json.JSONObject;
+import com.nimbusds.jwt.JWTClaimsSet;
+import com.nimbusds.jwt.SignedJWT;
+
+import java.io.InputStream;
+import java.security.KeyFactory;
+import java.security.KeyPair;
+import java.security.KeyPairGenerator;
+import java.security.NoSuchAlgorithmException;
+import java.security.PrivateKey;
+import java.security.PublicKey;
+import java.security.spec.PKCS8EncodedKeySpec;
+import java.security.spec.X509EncodedKeySpec;
+import java.util.Base64;
+import java.util.List;
+
+/**
+ * Utilities for generating a JWT for testing
+ */
+public class TokenUtils {
Review Comment:
Nothing from this class is used anywhere. The JavaDoc says it's used for
testing, but there are no tests. This class seems unnecessary at this point.
Issue Time Tracking
---
Worklog Id: (was: 866830)
Time Spent: 1h (was: 50m)
> Add JWT authentication plugin
> -
>
> Key: AMQ-9244
> URL: https://issues.apache.org/jira/browse/AMQ-9244
> Project: ActiveMQ
> Issue Type: Task
> Components: Security/JAAS
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.19.0, 5.18.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[
https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866829&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866829
]
ASF GitHub Bot logged work on AMQ-9244:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 19:23
Start Date: 21/Jun/23 19:23
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #1035:
URL: https://github.com/apache/activemq/pull/1035#discussion_r1237577663
##
activemq-broker/src/main/java/org/apache/activemq/security/jwt/JwtAuthenticationPlugin.java:
##
@@ -0,0 +1,60 @@
+/**
+ * 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.security.jwt;
+
+import com.nimbusds.jose.JWSAlgorithm;
+import org.apache.activemq.broker.Broker;
+import org.apache.activemq.broker.BrokerPlugin;
+
+/**
+ * A simple JWT plugin giving ActiveMQ the ability to support JWT tokens to
authenticate and authorize users
+ *
+ * @org.apache.xbean.XBean element="jwtAuthenticationPlugin"
+ * description="Provides a JWT authentication plugin"
+ *
+ *
+ * This plugin is rather simple and is only meant to be used as a first step.
In real world applications, we would need
+ * to being able to specify different key format (RSA, DSA, EC, etc), the
issuer, the claim to use for groups and maybe
+ * some mapping functionalities.
+ * The header name is also hard coded for simplicity.
+ */
+public class JwtAuthenticationPlugin implements BrokerPlugin {
Review Comment:
Perhaps I'm wrong, but this doesn't appear usable as is. How can users
configure these values? Is the idea here that they will need implement and
deploy their own version of this class in order to configure auth as needed? If
so, are there plans to make this configurable in the future?
Issue Time Tracking
---
Worklog Id: (was: 866829)
Time Spent: 50m (was: 40m)
> Add JWT authentication plugin
> -
>
> Key: AMQ-9244
> URL: https://issues.apache.org/jira/browse/AMQ-9244
> Project: ActiveMQ
> Issue Type: Task
> Components: Security/JAAS
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.19.0, 5.18.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[
https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866828&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866828
]
ASF GitHub Bot logged work on AMQ-9244:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 19:20
Start Date: 21/Jun/23 19:20
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #1035:
URL: https://github.com/apache/activemq/pull/1035#discussion_r1237570092
##
activemq-broker/src/main/java/org/apache/activemq/security/jwt/Claims.java:
##
@@ -0,0 +1,104 @@
+/**
+ * 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.security.jwt;
+
+import com.fasterxml.jackson.annotation.JsonValue;
+
+import java.util.Set;
+
+public enum Claims {
Review Comment:
What exactly are all the values, and why are so many unused values needed?
Issue Time Tracking
---
Worklog Id: (was: 866828)
Time Spent: 40m (was: 0.5h)
> Add JWT authentication plugin
> -
>
> Key: AMQ-9244
> URL: https://issues.apache.org/jira/browse/AMQ-9244
> Project: ActiveMQ
> Issue Type: Task
> Components: Security/JAAS
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.19.0, 5.18.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[ https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866827&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866827 ] ASF GitHub Bot logged work on AMQ-9244: --- Author: ASF GitHub Bot Created on: 21/Jun/23 19:19 Start Date: 21/Jun/23 19:19 Worklog Time Spent: 10m Work Description: jbertram commented on code in PR #1035: URL: https://github.com/apache/activemq/pull/1035#discussion_r1237566439 ## activemq-broker/pom.xml: ## @@ -66,6 +66,18 @@ activemq-jaas true + + com.nimbusds + nimbus-jose-jwt + 9.22 + true + + + org.bitbucket.b_c + jose4j + 0.7.9 Review Comment: The latest version is `0.9.3`. How come an older version is being used instead of the latest? Issue Time Tracking --- Worklog Id: (was: 866827) Time Spent: 0.5h (was: 20m) > Add JWT authentication plugin > - > > Key: AMQ-9244 > URL: https://issues.apache.org/jira/browse/AMQ-9244 > Project: ActiveMQ > Issue Type: Task > Components: Security/JAAS >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.19.0, 5.18.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9244) Add JWT authentication plugin
[ https://issues.apache.org/jira/browse/AMQ-9244?focusedWorklogId=866826&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866826 ] ASF GitHub Bot logged work on AMQ-9244: --- Author: ASF GitHub Bot Created on: 21/Jun/23 19:18 Start Date: 21/Jun/23 19:18 Worklog Time Spent: 10m Work Description: jbertram commented on code in PR #1035: URL: https://github.com/apache/activemq/pull/1035#discussion_r1237565253 ## activemq-broker/pom.xml: ## @@ -66,6 +66,18 @@ activemq-jaas true + + com.nimbusds + nimbus-jose-jwt + 9.22 Review Comment: The latest version is `9.31`. How come an older version is being used instead of the latest? Issue Time Tracking --- Worklog Id: (was: 866826) Time Spent: 20m (was: 10m) > Add JWT authentication plugin > - > > Key: AMQ-9244 > URL: https://issues.apache.org/jira/browse/AMQ-9244 > Project: ActiveMQ > Issue Type: Task > Components: Security/JAAS >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.19.0, 5.18.2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4323) Upgrade to Apache parent 30
[ https://issues.apache.org/jira/browse/ARTEMIS-4323?focusedWorklogId=866809&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866809 ] ASF GitHub Bot logged work on ARTEMIS-4323: --- Author: ASF GitHub Bot Created on: 21/Jun/23 18:01 Start Date: 21/Jun/23 18:01 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4521: URL: https://github.com/apache/activemq-artemis/pull/4521 (no comment) Issue Time Tracking --- Worklog Id: (was: 866809) Remaining Estimate: 0h Time Spent: 10m > Upgrade to Apache parent 30 > --- > > Key: ARTEMIS-4323 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4323 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >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-4323) Upgrade to Apache parent 30
Justin Bertram created ARTEMIS-4323: --- Summary: Upgrade to Apache parent 30 Key: ARTEMIS-4323 URL: https://issues.apache.org/jira/browse/ARTEMIS-4323 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?focusedWorklogId=866801&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866801
]
ASF GitHub Bot logged work on ARTEMIS-4319:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 16:43
Start Date: 21/Jun/23 16:43
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4512:
URL: https://github.com/apache/activemq-artemis/pull/4512#discussion_r1237298128
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerLogger.java:
##
@@ -1573,13 +1573,13 @@ void slowConsumerDetected(String sessionID,
@LogMessage(id = 224122, value = "Address {} number of messages is under
page limit again, and it should be allowed to page again.", level =
LogMessage.Level.INFO)
void pageFree(SimpleString address);
- @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {},
based on the limitPageBytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
- void pageFullMaxBytes(SimpleString address, long pages, long maxPages, long
limitBytes, long bytes);
+ @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {}
based on the page-limit-bytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
+ void pageFullMaxBytes(SimpleString address, long pages, Long maxPages, Long
limitBytes, int bytes);
Review Comment:
Fair enough..the change here is certainly an improvement, so I've merged
it...does seem like it woudl be worth looking at why it was logging at all
though.
Issue Time Tracking
---
Worklog Id: (was: 866801)
Time Spent: 50m (was: 40m)
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?focusedWorklogId=866802&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866802
]
ASF GitHub Bot logged work on ARTEMIS-4319:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 16:43
Start Date: 21/Jun/23 16:43
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4512:
URL: https://github.com/apache/activemq-artemis/pull/4512#discussion_r1237298128
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerLogger.java:
##
@@ -1573,13 +1573,13 @@ void slowConsumerDetected(String sessionID,
@LogMessage(id = 224122, value = "Address {} number of messages is under
page limit again, and it should be allowed to page again.", level =
LogMessage.Level.INFO)
void pageFree(SimpleString address);
- @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {},
based on the limitPageBytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
- void pageFullMaxBytes(SimpleString address, long pages, long maxPages, long
limitBytes, long bytes);
+ @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {}
based on the page-limit-bytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
+ void pageFullMaxBytes(SimpleString address, long pages, Long maxPages, Long
limitBytes, int bytes);
Review Comment:
Fair enough..the change here is certainly an improvement, so I've merged
it...does seem like it would be worth looking at why it was logging at all
though.
Issue Time Tracking
---
Worklog Id: (was: 866802)
Time Spent: 1h (was: 50m)
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?focusedWorklogId=866799&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866799
]
ASF GitHub Bot logged work on ARTEMIS-4319:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 16:42
Start Date: 21/Jun/23 16:42
Worklog Time Spent: 10m
Work Description: gemmellr merged PR #4512:
URL: https://github.com/apache/activemq-artemis/pull/4512
Issue Time Tracking
---
Worklog Id: (was: 866799)
Time Spent: 40m (was: 0.5h)
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735815#comment-17735815
]
ASF subversion and git services commented on ARTEMIS-4319:
--
Commit dc4bf953e3113f4857a3573e3e81bdc627cc5304 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=dc4bf953e3 ]
ARTEMIS-4319 mitigate NPE in paging log statement
Also improves the wording of some several related statements.
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?focusedWorklogId=866794&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866794
]
ASF GitHub Bot logged work on ARTEMIS-4319:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 16:13
Start Date: 21/Jun/23 16:13
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4512:
URL: https://github.com/apache/activemq-artemis/pull/4512#discussion_r1237260437
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerLogger.java:
##
@@ -1573,13 +1573,13 @@ void slowConsumerDetected(String sessionID,
@LogMessage(id = 224122, value = "Address {} number of messages is under
page limit again, and it should be allowed to page again.", level =
LogMessage.Level.INFO)
void pageFree(SimpleString address);
- @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {},
based on the limitPageBytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
- void pageFullMaxBytes(SimpleString address, long pages, long maxPages, long
limitBytes, long bytes);
+ @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {}
based on the page-limit-bytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
+ void pageFullMaxBytes(SimpleString address, long pages, Long maxPages, Long
limitBytes, int bytes);
Review Comment:
I'm not entirely sure how this gets logged when the limit is `null`. This is
what was reported by a user on the [mailing
list](https://lists.apache.org/thread/j9v7j6w0hff0sbmhn7qyzy79cj54ohhv):
> My hunch is that once we set a limit, we cannot remove the section
completely, so set a very low `` and start the broker, let
the address start paging and then remove the `` completely
from address setting.
It looks like there may be other, larger issues present, but I wanted to
mitigate the NPE before going deeper.
Issue Time Tracking
---
Worklog Id: (was: 866794)
Time Spent: 0.5h (was: 20m)
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4322) BundleFactory should use PrivilegedAction
[
https://issues.apache.org/jira/browse/ARTEMIS-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4322:
Description: Since migrating to SLF4J folks running in the context of a
[SecurityManager|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/SecurityManager.html]
can have problems since {{org.apache.activemq.artemis.logs.BundleFactory}} is
not using a {{java.security.PrivilegedAction}}
> BundleFactory should use PrivilegedAction
> -
>
> Key: ARTEMIS-4322
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4322
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since migrating to SLF4J folks running in the context of a
> [SecurityManager|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/SecurityManager.html]
> can have problems since {{org.apache.activemq.artemis.logs.BundleFactory}}
> is not using a {{java.security.PrivilegedAction}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4322) BundleFactory should use PrivilegedAction
[ https://issues.apache.org/jira/browse/ARTEMIS-4322?focusedWorklogId=866790&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866790 ] ASF GitHub Bot logged work on ARTEMIS-4322: --- Author: ASF GitHub Bot Created on: 21/Jun/23 15:40 Start Date: 21/Jun/23 15:40 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4520: URL: https://github.com/apache/activemq-artemis/pull/4520 (no comment) Issue Time Tracking --- Worklog Id: (was: 866790) Remaining Estimate: 0h Time Spent: 10m > BundleFactory should use PrivilegedAction > - > > Key: ARTEMIS-4322 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4322 > 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-4322) BundleFactory should use PrivilegedAction
Justin Bertram created ARTEMIS-4322: --- Summary: BundleFactory should use PrivilegedAction Key: ARTEMIS-4322 URL: https://issues.apache.org/jira/browse/ARTEMIS-4322 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4321) Upgrade Guava to 32.0.1-jre
[ https://issues.apache.org/jira/browse/ARTEMIS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4321: Summary: Upgrade Guava to 32.0.1-jre (was: Upgrade Guava to 32.0.0-jre) > Upgrade Guava to 32.0.1-jre > --- > > Key: ARTEMIS-4321 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4321 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4321) Upgrade Guava to 32.0.1-jre
[ https://issues.apache.org/jira/browse/ARTEMIS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4321. - Fix Version/s: 2.30.0 Resolution: Fixed > Upgrade Guava to 32.0.1-jre > --- > > Key: ARTEMIS-4321 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4321 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.30.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4321) Upgrade Guava to 32.0.0-jre
[ https://issues.apache.org/jira/browse/ARTEMIS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735777#comment-17735777 ] ASF subversion and git services commented on ARTEMIS-4321: -- Commit 7ff5f47008d7280b52c479f962f6f95b5e280ed3 in activemq-artemis's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7ff5f47008 ] ARTEMIS-4321: upgrade Guava to 32.0.1-jre > Upgrade Guava to 32.0.0-jre > --- > > Key: ARTEMIS-4321 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4321 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4311) Strange typo propagated throughout the codebase: "Mesasge"
[ https://issues.apache.org/jira/browse/ARTEMIS-4311 ] Robbie Gemmell deleted comment on ARTEMIS-4311: - was (Author: jira-bot): Commit b316272e145c9c96fc6adf274452eec52051675b in activemq-artemis's branch refs/heads/dependabot/maven/com.google.guava-guava-32.0.0-jre from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b316272e14 ] ARTEMIS-4311 fix typo > Strange typo propagated throughout the codebase: "Mesasge" > -- > > Key: ARTEMIS-4311 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4311 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.29.0 >Reporter: Geert Schuring >Assignee: Justin Bertram >Priority: Minor > Fix For: 2.30.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Somehow the same typo appears in 23 files. See > [https://github.com/search?q=repo%3Aapache%2Factivemq-artemis%20mesasge&type=code] > Nothing major, but a bit cringe to see this in the config of every broker I > create :) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4316) Example HTML does not render correctly
[ https://issues.apache.org/jira/browse/ARTEMIS-4316 ] Robbie Gemmell deleted comment on ARTEMIS-4316: - was (Author: jira-bot): Commit 42c93fc7d215c3ad7d18143d782649a1737219f6 in activemq-artemis's branch refs/heads/dependabot/maven/com.google.guava-guava-32.0.0-jre from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=42c93fc7d2 ] ARTEMIS-4316 fix example doc formatting This commit also updates the artifact used to generate the HTML from the MarkDown as the existing artifact is now defunct. > Example HTML does not render correctly > -- > > Key: ARTEMIS-4316 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4316 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.29.0 >Reporter: Geert Schuring >Assignee: Justin Bertram >Priority: Major > Labels: documentation, examples, html, rendering > Fix For: 2.30.0 > > Attachments: image-2023-06-16-10-43-45-924.png > > Time Spent: 20m > Remaining Estimate: 0h > > The HTML files in the examples do not render correctly. Especially the code > parts. For example, the Readme in the CDI example: > apache-artemis-2.28.0/examples/features/standard/cdi/readme.html > !image-2023-06-16-10-43-45-924.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4275: - Assignee: Justin Bertram > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Assignee: Justin Bertram >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4291) Some metrics do not have the "broker" tag
[
https://issues.apache.org/jira/browse/ARTEMIS-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4291.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> Some metrics do not have the "broker" tag
> -
>
> Key: ARTEMIS-4291
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4291
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Roelof Naude
>Priority: Minor
> Fix For: 2.29.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Some metrics do not have the "broker" tag. The "broker" may not match the
> "instance" added by e.g. prometheus, leading to a mismatch.
> [MetricsManager|https://github.com/apache/activemq-artemis/blob/2.28.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/metrics/MetricsManager.java]
> should ideally add "broker" to the common tags, e.g:
> {code:java}
> meterRegistry.config().commonTags("broker", brokerName);{code}
>
> [PR 4487|https://github.com/apache/activemq-artemis/pull/4487] was submitted
> to resolve this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4291) Some metrics do not have the "broker" tag
[
https://issues.apache.org/jira/browse/ARTEMIS-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4291:
-
> Some metrics do not have the "broker" tag
> -
>
> Key: ARTEMIS-4291
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4291
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Roelof Naude
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Some metrics do not have the "broker" tag. The "broker" may not match the
> "instance" added by e.g. prometheus, leading to a mismatch.
> [MetricsManager|https://github.com/apache/activemq-artemis/blob/2.28.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/metrics/MetricsManager.java]
> should ideally add "broker" to the common tags, e.g:
> {code:java}
> meterRegistry.config().commonTags("broker", brokerName);{code}
>
> [PR 4487|https://github.com/apache/activemq-artemis/pull/4487] was submitted
> to resolve this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[ https://issues.apache.org/jira/browse/ARTEMIS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4312: - > Duplicates with redistribution and multiple multicast queues on the same > address > > > Key: ARTEMIS-4312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4312 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Consider a set-up with two brokers clustered together and redistribution > enabled and a address with about a dozen multicast subscription queues bound > to it. If a consumer of one of those subscriptions goes offline, messages > will begin to build up in the queue (as expected). When the consumer comes > back online, whatever broker it attaches to first will have messages > redistributed from the other broker in the cluster. When this redistribution > happens the other multicast queues receive some of those redistributed > messages (although not all of them) even though they had already received > them previously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4275. --- Fix Version/s: 2.29.0 Resolution: Fixed > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[ https://issues.apache.org/jira/browse/ARTEMIS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4312. --- Fix Version/s: 2.29.0 Resolution: Fixed > Duplicates with redistribution and multiple multicast queues on the same > address > > > Key: ARTEMIS-4312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4312 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Consider a set-up with two brokers clustered together and redistribution > enabled and a address with about a dozen multicast subscription queues bound > to it. If a consumer of one of those subscriptions goes offline, messages > will begin to build up in the queue (as expected). When the consumer comes > back online, whatever broker it attaches to first will have messages > redistributed from the other broker in the cluster. When this redistribution > happens the other multicast queues receive some of those redistributed > messages (although not all of them) even though they had already received > them previously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4285: - Assignee: Clebert Suconic > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4237) Move SoakPagingTest and ReplicationFlowControlTest into soak-tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4237: - Assignee: Clebert Suconic > Move SoakPagingTest and ReplicationFlowControlTest into soak-tests > -- > > Key: ARTEMIS-4237 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4237 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > These two tests were written before an actual soak-tests project existed. So > they should be moved now that there is one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4237) Move SoakPagingTest and ReplicationFlowControlTest into soak-tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4237. --- Fix Version/s: 2.29.0 Resolution: Fixed > Move SoakPagingTest and ReplicationFlowControlTest into soak-tests > -- > > Key: ARTEMIS-4237 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4237 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > These two tests were written before an actual soak-tests project existed. So > they should be moved now that there is one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4215) JournalFlush might never happen when journal-sync-* is false
[ https://issues.apache.org/jira/browse/ARTEMIS-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4215. --- Fix Version/s: 2.29.0 Resolution: Fixed > JournalFlush might never happen when journal-sync-* is false > > > Key: ARTEMIS-4215 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4215 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > When journal-sync-* is false then flushes to journal will only ever happen > once the buffer is full or when the broker is cleanly shut down, regardless > of how much time passes. This means that if the broker is started with these > settings a crash/kill -9 will for sure loose messages, regardless of how much > time passes since the messages where sent. > This started with version 2.18.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4215) JournalFlush might never happen when journal-sync-* is false
[ https://issues.apache.org/jira/browse/ARTEMIS-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4215: - Assignee: Clebert Suconic > JournalFlush might never happen when journal-sync-* is false > > > Key: ARTEMIS-4215 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4215 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Assignee: Clebert Suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > When journal-sync-* is false then flushes to journal will only ever happen > once the buffer is full or when the broker is cleanly shut down, regardless > of how much time passes. This means that if the broker is started with these > settings a crash/kill -9 will for sure loose messages, regardless of how much > time passes since the messages where sent. > This started with version 2.18.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4285. --- Fix Version/s: 2.29.0 Resolution: Fixed > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4186) Ability to set compressionLevel for compressLargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4186. --- Fix Version/s: 2.29.0 Resolution: Fixed > Ability to set compressionLevel for compressLargeMessages > - > > Key: ARTEMIS-4186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4186 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4143) Improve mitigation against split-brain with shared-storage
[ https://issues.apache.org/jira/browse/ARTEMIS-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4143: - > Improve mitigation against split-brain with shared-storage > -- > > Key: ARTEMIS-4143 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4143 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4186) Ability to set compressionLevel for compressLargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4186: - > Ability to set compressionLevel for compressLargeMessages > - > > Key: ARTEMIS-4186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4186 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4143) Improve mitigation against split-brain with shared-storage
[ https://issues.apache.org/jira/browse/ARTEMIS-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4143. --- Fix Version/s: 2.29.0 Resolution: Fixed > Improve mitigation against split-brain with shared-storage > -- > > Key: ARTEMIS-4143 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4143 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4183) Broker diagram is not properly updated when new nodes become available
[
https://issues.apache.org/jira/browse/ARTEMIS-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4183.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> Broker diagram is not properly updated when new nodes become available
> --
>
> Key: ARTEMIS-4183
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4183
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.29.0
>
> Attachments: image-2023-02-26-16-36-25-761.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using an auto discovery cluster.
> When the number of nodes is reduced, the broker diagram is properly updated
> when the Refresh button is used.
> When the number of nodes is enlarged, the broker diagram is _not_ properly
> updated when the Refresh button is used. The new nodes are visible, but their
> cluster-connections are not shown. The diagram can easily be fixed by using
> the browser refresh button instead, or by temporarily switching tabs within
> the Artemis console.
> The following diagram shows the effect:
> !image-2023-02-26-16-36-25-761.png!
> left image: initial situation with 5 nodes
> middle image: 3 nodes are added, and after Refresh button is used
> right image: after page refresh
> -I know the JS code from the Console fairly well. I suspect a synchronisation
> error between the variables {{relations}} and {{{}hiddenRelations{}}}. I'll
> investigate and try to add a PR.-
> A PR is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4183) Broker diagram is not properly updated when new nodes become available
[
https://issues.apache.org/jira/browse/ARTEMIS-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4183:
-
> Broker diagram is not properly updated when new nodes become available
> --
>
> Key: ARTEMIS-4183
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4183
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: image-2023-02-26-16-36-25-761.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using an auto discovery cluster.
> When the number of nodes is reduced, the broker diagram is properly updated
> when the Refresh button is used.
> When the number of nodes is enlarged, the broker diagram is _not_ properly
> updated when the Refresh button is used. The new nodes are visible, but their
> cluster-connections are not shown. The diagram can easily be fixed by using
> the browser refresh button instead, or by temporarily switching tabs within
> the Artemis console.
> The following diagram shows the effect:
> !image-2023-02-26-16-36-25-761.png!
> left image: initial situation with 5 nodes
> middle image: 3 nodes are added, and after Refresh button is used
> right image: after page refresh
> -I know the JS code from the Console fairly well. I suspect a synchronisation
> error between the variables {{relations}} and {{{}hiddenRelations{}}}. I'll
> investigate and try to add a PR.-
> A PR is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4268) AMQPMessage copy constructor shouldn't copy all message annotations
[ https://issues.apache.org/jira/browse/ARTEMIS-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4268. --- Fix Version/s: 2.29.0 Resolution: Fixed > AMQPMessage copy constructor shouldn't copy all message annotations > --- > > Key: ARTEMIS-4268 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4268 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1h > Remaining Estimate: 0h > > During redistribution, we should not copy all message annotations. > In particular we should not copy any of the x-opt-ORIG annotations used on > DLQ and other copies. > this was broken after f632e8104bbdae1fbf3658fec47e180784e957da (ARTEMIS-3833 > Preserve JMSCorrelationID of distributed AMQP large messages) > The change preserved too much, and as a result of that > AmqpLargeMessageRedistributionTest::testSendMessageToBroker0GetFromBroker2 is > intermittently failing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4268) AMQPMessage copy constructor shouldn't copy all message annotations
[ https://issues.apache.org/jira/browse/ARTEMIS-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4268: - Assignee: Clebert Suconic > AMQPMessage copy constructor shouldn't copy all message annotations > --- > > Key: ARTEMIS-4268 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4268 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > During redistribution, we should not copy all message annotations. > In particular we should not copy any of the x-opt-ORIG annotations used on > DLQ and other copies. > this was broken after f632e8104bbdae1fbf3658fec47e180784e957da (ARTEMIS-3833 > Preserve JMSCorrelationID of distributed AMQP large messages) > The change preserved too much, and as a result of that > AmqpLargeMessageRedistributionTest::testSendMessageToBroker0GetFromBroker2 is > intermittently failing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-2824. --- Fix Version/s: 2.29.0 Resolution: Fixed > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-2824: - > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4281) Queue Reaper may remove non empty queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4281: - > Queue Reaper may remove non empty queues > > > Key: ARTEMIS-4281 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4281 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > > Say you configure the auto delete queue with > .setAutoDeleteQueuesMessageCount(-1). > We shouldn't reap non empty queues during the initial reaping phase. This is > because you could have a failed over client moving to the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4252) Fix flaky QuorumFailOverTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4252. --- Fix Version/s: 2.29.0 Resolution: Fixed > Fix flaky QuorumFailOverTest tests > -- > > Key: ARTEMIS-4252 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4252 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > QuorumFailOverTest tests are intermittently failing. To fix > QuorumFailOverTest tests, we should wait for cluster bridge connections. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4281) Queue Reaper may remove non empty queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4281. --- Fix Version/s: 2.29.0 Resolution: Fixed > Queue Reaper may remove non empty queues > > > Key: ARTEMIS-4281 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4281 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > > Say you configure the auto delete queue with > .setAutoDeleteQueuesMessageCount(-1). > We shouldn't reap non empty queues during the initial reaping phase. This is > because you could have a failed over client moving to the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4252) Fix flaky QuorumFailOverTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4252: - > Fix flaky QuorumFailOverTest tests > -- > > Key: ARTEMIS-4252 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4252 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > QuorumFailOverTest tests are intermittently failing. To fix > QuorumFailOverTest tests, we should wait for cluster bridge connections. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3809.
-
Fix Version/s: 2.29.0
Resolution: Fixed
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Assignee: Clebert Suconic
>Priority: Major
> Labels: test-stability
> Fix For: 2.29.0
>
> Attachments: image-2022-05-03-10-51-46-872.png
>
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes across the
> threshold to become large it appears to hang the consumer indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-3809:
-
Assignee: Clebert Suconic
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Assignee: Clebert Suconic
>Priority: Major
> Labels: test-stability
> Attachments: image-2022-05-03-10-51-46-872.png
>
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes across the
> threshold to become large it appears to hang the consumer indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4290) Move some tests out of integration-tests into a new module where these tests will run individually
[ https://issues.apache.org/jira/browse/ARTEMIS-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4290. --- Fix Version/s: 2.29.0 Resolution: Fixed > Move some tests out of integration-tests into a new module where these tests > will run individually > -- > > Key: ARTEMIS-4290 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4290 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some tests will leak threads affecting further tests. For these tests they > should always be forked on their own tests. > Instead of re-engineering a lot of theset tests we are creating > integrated-tests-isolated which is pretty much a copy of integration-tests > however these tests will run with forkMode=always on the maven plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4253) disabling a few ActiveMQServerControlUsingCoreTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4253. --- Fix Version/s: 2.29.0 Resolution: Fixed > disabling a few ActiveMQServerControlUsingCoreTest tests > > > Key: ARTEMIS-4253 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4253 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > some of these tests are adding noise to the test. > For example you count how many sessions you have, however the framework to > send and receive notifications itself is creating a sessions. Some times > (intermittently) these sessions are affecting the counts, what makes these > tests invalid and they should be ignored on the UsingCoreTests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4253) disabling a few ActiveMQServerControlUsingCoreTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4253: - Assignee: Clebert Suconic > disabling a few ActiveMQServerControlUsingCoreTest tests > > > Key: ARTEMIS-4253 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4253 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > some of these tests are adding noise to the test. > For example you count how many sessions you have, however the framework to > send and receive notifications itself is creating a sessions. Some times > (intermittently) these sessions are affecting the counts, what makes these > tests invalid and they should be ignored on the UsingCoreTests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4293) Add management ops to clear authn/z caches
[ https://issues.apache.org/jira/browse/ARTEMIS-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4293: - > Add management ops to clear authn/z caches > -- > > Key: ARTEMIS-4293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4293 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4190) config-delete-queues doesn't always work as expected
[
https://issues.apache.org/jira/browse/ARTEMIS-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4190.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> config-delete-queues doesn't always work as expected
>
>
> Key: ARTEMIS-4190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4190
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Setting config-delete-queues + config-delete-addresses seems not to work as
> expected in the use case where the original multicast address remains, but
> the fixed queues within the multicast address are moved to anycast addresses.
> Consider the following case:
> We start with two multicast addresses, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We change the addresses to move the internal queues out of the multicast
> addresses and to anycast addresses, but keeping the original multicast
> addresses themselves, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We end up with the queues remaining in the multicast addresses, along with
> new anycast queues of the same name as anycast queues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4290) Move some tests out of integration-tests into a new module where these tests will run individually
[ https://issues.apache.org/jira/browse/ARTEMIS-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4290: - Assignee: Clebert Suconic > Move some tests out of integration-tests into a new module where these tests > will run individually > -- > > Key: ARTEMIS-4290 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4290 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Some tests will leak threads affecting further tests. For these tests they > should always be forked on their own tests. > Instead of re-engineering a lot of theset tests we are creating > integrated-tests-isolated which is pretty much a copy of integration-tests > however these tests will run with forkMode=always on the maven plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4293) Add management ops to clear authn/z caches
[ https://issues.apache.org/jira/browse/ARTEMIS-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4293. --- Fix Version/s: 2.29.0 Resolution: Fixed > Add management ops to clear authn/z caches > -- > > Key: ARTEMIS-4293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4293 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4190) config-delete-queues doesn't always work as expected
[
https://issues.apache.org/jira/browse/ARTEMIS-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4190:
-
> config-delete-queues doesn't always work as expected
>
>
> Key: ARTEMIS-4190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4190
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Setting config-delete-queues + config-delete-addresses seems not to work as
> expected in the use case where the original multicast address remains, but
> the fixed queues within the multicast address are moved to anycast addresses.
> Consider the following case:
> We start with two multicast addresses, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We change the addresses to move the internal queues out of the multicast
> addresses and to anycast addresses, but keeping the original multicast
> addresses themselves, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We end up with the queues remaining in the multicast addresses, along with
> new anycast queues of the same name as anycast queues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4254) Transactional / Replication Soak Test
[ https://issues.apache.org/jira/browse/ARTEMIS-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4254. --- Fix Version/s: 2.29.0 Resolution: Fixed > Transactional / Replication Soak Test > - > > Key: ARTEMIS-4254 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4254 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I recently developed a replication test under soak-test to validate producing > into a topic a failing over during the producers. > Even though I did not find anything wrong with the test, I am still > committing the test. (There is not enough testing, so... just one more to > ensure transaction and replication). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4274) Push masked credential support into core client
[
https://issues.apache.org/jira/browse/ARTEMIS-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4274.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> Push masked credential support into core client
> ---
>
> Key: ARTEMIS-4274
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4274
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently masked credentials are only supported in the core JMS client. This
> support should be pushed down into the core client itself so things like CLI
> utilities (e.g. {{queue stat}}, {{check node}}) can use it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4278) Incorrect Page Counters when using Prepared Transactions with Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4278. --- Fix Version/s: 2.29.0 Resolution: Fixed > Incorrect Page Counters when using Prepared Transactions with Paging > > > Key: ARTEMIS-4278 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4278 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The system is not reloading the state on afterCommit for prepared > Transactions in relation to the page counters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4274) Push masked credential support into core client
[
https://issues.apache.org/jira/browse/ARTEMIS-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4274:
-
> Push masked credential support into core client
> ---
>
> Key: ARTEMIS-4274
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4274
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently masked credentials are only supported in the core JMS client. This
> support should be pushed down into the core client itself so things like CLI
> utilities (e.g. {{queue stat}}, {{check node}}) can use it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4254) Transactional / Replication Soak Test
[ https://issues.apache.org/jira/browse/ARTEMIS-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4254: - > Transactional / Replication Soak Test > - > > Key: ARTEMIS-4254 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4254 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > I recently developed a replication test under soak-test to validate producing > into a topic a failing over during the producers. > Even though I did not find anything wrong with the test, I am still > committing the test. (There is not enough testing, so... just one more to > ensure transaction and replication). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4283) Fail fast CORE client connect on closing
[ https://issues.apache.org/jira/browse/ARTEMIS-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4283: - > Fail fast CORE client connect on closing > > > Key: ARTEMIS-4283 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4283 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > ServerLocatorImpl waits for topology after connecting a new session factory. > It should interrupt waiting for topology when it is closed to fail fast. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4185. --- Fix Version/s: 2.29.0 Resolution: Fixed > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4278) Incorrect Page Counters when using Prepared Transactions with Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4278: - Assignee: Clebert Suconic > Incorrect Page Counters when using Prepared Transactions with Paging > > > Key: ARTEMIS-4278 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4278 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The system is not reloading the state on afterCommit for prepared > Transactions in relation to the page counters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4283) Fail fast CORE client connect on closing
[ https://issues.apache.org/jira/browse/ARTEMIS-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4283. --- Fix Version/s: 2.29.0 Resolution: Fixed > Fail fast CORE client connect on closing > > > Key: ARTEMIS-4283 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4283 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > > ServerLocatorImpl waits for topology after connecting a new session factory. > It should interrupt waiting for topology when it is closed to fail fast. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4185: - > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4259.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4309) Large JMS ObjectMessage types result in UTFDataFormatException when deserialized on client side
[ https://issues.apache.org/jira/browse/ARTEMIS-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4309. --- Fix Version/s: 2.29.0 Resolution: Fixed > Large JMS ObjectMessage types result in UTFDataFormatException when > deserialized on client side > --- > > Key: ARTEMIS-4309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4309 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: peter brady >Priority: Minor > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When an activemq classic client uses the compression option to create a > connection with the Artemis broker, ObjectMessage types greater than 1024 > bytes have a problem being deserialized on the consumer side. The process > consuming the message attempts to reconstruct the Java object from the data > contained in the received ObjectMessage, but then throws a > UTFDataFormatException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4309) Large JMS ObjectMessage types result in UTFDataFormatException when deserialized on client side
[ https://issues.apache.org/jira/browse/ARTEMIS-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4309: - > Large JMS ObjectMessage types result in UTFDataFormatException when > deserialized on client side > --- > > Key: ARTEMIS-4309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4309 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: peter brady >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > When an activemq classic client uses the compression option to create a > connection with the Artemis broker, ObjectMessage types greater than 1024 > bytes have a problem being deserialized on the consumer side. The process > consuming the message attempts to reconstruct the Java object from the data > contained in the received ObjectMessage, but then throws a > UTFDataFormatException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4259:
-
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4238. --- Fix Version/s: 2.29.0 Resolution: Fixed > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4265.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4265:
-
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4238: - Assignee: Justin Bertram > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4169) Auto detect dead-letter and expiry queues in the console
[ https://issues.apache.org/jira/browse/ARTEMIS-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4169. --- Fix Version/s: 2.29.0 Resolution: Fixed > Auto detect dead-letter and expiry queues in the console > > > Key: ARTEMIS-4169 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4169 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The custom DLQ do not show some options/columns on hawtio. For this we have > to configure "Dead-letter address regex" on the management console. > The console browse plugin could auto-detect dead-letter and expiry queues by > checking the `_AMQ_ORIG_QUEUE` property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4244. --- Fix Version/s: 2.29.0 Resolution: Fixed > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4169) Auto detect dead-letter and expiry queues in the console
[ https://issues.apache.org/jira/browse/ARTEMIS-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4169: - > Auto detect dead-letter and expiry queues in the console > > > Key: ARTEMIS-4169 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4169 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The custom DLQ do not show some options/columns on hawtio. For this we have > to configure "Dead-letter address regex" on the management console. > The console browse plugin could auto-detect dead-letter and expiry queues by > checking the `_AMQ_ORIG_QUEUE` property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4244: - > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4279) CriticalAnalyzer thread does not shut down if error during broker initialization
[ https://issues.apache.org/jira/browse/ARTEMIS-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4279. --- Fix Version/s: 2.29.0 Resolution: Fixed > CriticalAnalyzer thread does not shut down if error during broker > initialization > > > Key: ARTEMIS-4279 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4279 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.29.0 >Reporter: Stephen Higgs >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > > During broker initialization, if there is an error at a very specific time > (creating nodemanager), the broker will stop but the critical analyzer thread > will continue to run, preventing the process from exiting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4279) CriticalAnalyzer thread does not shut down if error during broker initialization
[ https://issues.apache.org/jira/browse/ARTEMIS-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4279: - Assignee: Clebert Suconic > CriticalAnalyzer thread does not shut down if error during broker > initialization > > > Key: ARTEMIS-4279 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4279 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.29.0 >Reporter: Stephen Higgs >Assignee: Clebert Suconic >Priority: Major > > During broker initialization, if there is an error at a very specific time > (creating nodemanager), the broker will stop but the critical analyzer thread > will continue to run, preventing the process from exiting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4211) AMQ222153: Cannot locate record in bidirectional upstream queue federation
[
https://issues.apache.org/jira/browse/ARTEMIS-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4211.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> AMQ222153: Cannot locate record in bidirectional upstream queue federation
> --
>
> Key: ARTEMIS-4211
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4211
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Two consumers of the same queue connected to two distinct federated brokers
> with a bidirectional upstream queue federation can cause the following error:
> {code:java}
> [Thread-12
> (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$8@3e14c16d)]
> 17:55:45,171 WARN [org.apache.activemq.artemis.core.server] AMQ222153:
> Cannot locate record for message id = 260 on Journal
> java.lang.Exception: trace
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.messageUpdateCallback(AbstractJournalStorageManager.java:461)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl$3.run(JournalImpl.java:1194)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[classes/:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3640) external clients cannot use cluster topology for HA or load balancing
[
https://issues.apache.org/jira/browse/ARTEMIS-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-3640.
---
Fix Version/s: 2.29.0
Resolution: Fixed
> external clients cannot use cluster topology for HA or load balancing
> -
>
> Key: ARTEMIS-3640
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3640
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Vilius Šumskas
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Let's say there is a simple Artemis HA master/slave shared storage cluster
> with such configuration:
>
> {noformat}
>
> name="artemis-master">tcp://internal-cluster-dns-1:61616
> name="artemis-slave">tcp://internal-cluster-dns-2:61616
>
> {noformat}
> The cluster is using static discovery.
>
> Factory on internal clients are using:
> {noformat}
> (tcp://internal-cluster-dns-1:61616,tcp://internal-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> Those internal clients can successfully connect to the cluster and failover
> works as expected.
>
> However if there is also external clients which use external DNS/IP address
> of the cluster the topology doesn't return correct DNS name and the failover
> fails.
> {noformat}
> (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> {noformat}
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:
> AMQ214033: Cannot resolve host java.net.UnknownHostException:
> internal-cluster-dns-1{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4211) AMQ222153: Cannot locate record in bidirectional upstream queue federation
[
https://issues.apache.org/jira/browse/ARTEMIS-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4211:
-
> AMQ222153: Cannot locate record in bidirectional upstream queue federation
> --
>
> Key: ARTEMIS-4211
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4211
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Two consumers of the same queue connected to two distinct federated brokers
> with a bidirectional upstream queue federation can cause the following error:
> {code:java}
> [Thread-12
> (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$8@3e14c16d)]
> 17:55:45,171 WARN [org.apache.activemq.artemis.core.server] AMQ222153:
> Cannot locate record for message id = 260 on Journal
> java.lang.Exception: trace
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.messageUpdateCallback(AbstractJournalStorageManager.java:461)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl$3.run(JournalImpl.java:1194)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[classes/:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-3640) external clients cannot use cluster topology for HA or load balancing
[
https://issues.apache.org/jira/browse/ARTEMIS-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-3640:
-
Assignee: Domenico Francesco Bruscino (was: Gary Tully)
> external clients cannot use cluster topology for HA or load balancing
> -
>
> Key: ARTEMIS-3640
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3640
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Vilius Šumskas
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Let's say there is a simple Artemis HA master/slave shared storage cluster
> with such configuration:
>
> {noformat}
>
> name="artemis-master">tcp://internal-cluster-dns-1:61616
> name="artemis-slave">tcp://internal-cluster-dns-2:61616
>
> {noformat}
> The cluster is using static discovery.
>
> Factory on internal clients are using:
> {noformat}
> (tcp://internal-cluster-dns-1:61616,tcp://internal-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> Those internal clients can successfully connect to the cluster and failover
> works as expected.
>
> However if there is also external clients which use external DNS/IP address
> of the cluster the topology doesn't return correct DNS name and the failover
> fails.
> {noformat}
> (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> {noformat}
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:
> AMQ214033: Cannot resolve host java.net.UnknownHostException:
> internal-cluster-dns-1{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4292) Support additional Micrometer system metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4292. --- Fix Version/s: 2.29.0 Resolution: Fixed > Support additional Micrometer system metrics > > > Key: ARTEMIS-4292 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4292 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.29.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The broker already supports optional metrics for the JVM and Netty, but > Micrometer has a number of other metrics which would be useful to support as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4292) Support additional Micrometer system metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4292: - > Support additional Micrometer system metrics > > > Key: ARTEMIS-4292 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4292 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The broker already supports optional metrics for the JVM and Netty, but > Micrometer has a number of other metrics which would be useful to support as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4303) Artemis Windows Service fails to start correctly when filepath has a space
[ https://issues.apache.org/jira/browse/ARTEMIS-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4303. --- Fix Version/s: 2.29.0 Resolution: Fixed > Artemis Windows Service fails to start correctly when filepath has a space > -- > > Key: ARTEMIS-4303 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4303 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.28.0 > Environment: Windows 10 >Reporter: Jake Sperlazza >Priority: Minor > Fix For: 2.29.0 > > Attachments: artemis-service.out.log, artemis-service.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > Steps to reproduce: > # Download / extract zip: > [https://activemq.apache.org/components/artemis/download/] > # run "bin/artemis create" giving it a target path which has a space e.g.: > ## ./bin/artemis create --user default --password default --require-login > /c/Program\ Files/artemis > # Install and try and start the service > ## "C:\Program Files\artemis\bin\artemis-service.exe"install > ## "C:\Program Files\artemis\bin\artemis-service.exe" start > # Notice the web console does not come up and there are errors in the logs > (as shown in attachment artemis-service.out.log) > > I believe the problem lies in line 29 of the generated artemis-service.xml > (attached), which has a unnecessarily double-escaped space character (%%20) > for the value of ARTEMIS_INSTANCE_ETC_URI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4303) Artemis Windows Service fails to start correctly when filepath has a space
[ https://issues.apache.org/jira/browse/ARTEMIS-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4303: - > Artemis Windows Service fails to start correctly when filepath has a space > -- > > Key: ARTEMIS-4303 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4303 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.28.0 > Environment: Windows 10 >Reporter: Jake Sperlazza >Priority: Minor > Attachments: artemis-service.out.log, artemis-service.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > Steps to reproduce: > # Download / extract zip: > [https://activemq.apache.org/components/artemis/download/] > # run "bin/artemis create" giving it a target path which has a space e.g.: > ## ./bin/artemis create --user default --password default --require-login > /c/Program\ Files/artemis > # Install and try and start the service > ## "C:\Program Files\artemis\bin\artemis-service.exe"install > ## "C:\Program Files\artemis\bin\artemis-service.exe" start > # Notice the web console does not come up and there are errors in the logs > (as shown in attachment artemis-service.out.log) > > I believe the problem lies in line 29 of the generated artemis-service.xml > (attached), which has a unnecessarily double-escaped space character (%%20) > for the value of ARTEMIS_INSTANCE_ETC_URI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4177) Misleading documentation for "Logging the clients remote address"
[
https://issues.apache.org/jira/browse/ARTEMIS-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4177:
Fix Version/s: (was: 2.28.0)
> Misleading documentation for "Logging the clients remote address"
> -
>
> Key: ARTEMIS-4177
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4177
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration, JAAS
>Affects Versions: 2.27.1, 2.28.0
>Reporter: Dries Harnie
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.29.0
>
>
> In the [Logging chapter of the
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html],
> there is the following section:
> {quote}
> h3. Logging the clients remote address
> It is possible to configure the audit loggers to log the remote address of
> any calling clients either through normal clients or through the console and
> JMX. This is configured by enabling a specific login module in the login
> config file.
> {{org.apache.activemq.artemis.spi.core.security.jaas.AuditLoginModule optional
>debug=false;}}
> {quote}
> This actually accomplishes nothing, for the following reason:
> If you add this line to a block in login.conf and try to login to the broker,
> the Java {{LoginContext}} class will try to instantiate the class mentioned
> above using {{{}Class#newInstance{}}}. However, it is an interface (and has
> been for the past four years). It will thus throw an
> {{InstantiationException}} which is ignored because it is marked as an
> optional module.
> I assume this is a leftover from earlier development, because several other
> login modules _do_ implement the AuditLoginModule interface.
> Suggested fix is to remove this section entirely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4177) Misleading documentation for "Logging the clients remote address"
[
https://issues.apache.org/jira/browse/ARTEMIS-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4177:
-
> Misleading documentation for "Logging the clients remote address"
> -
>
> Key: ARTEMIS-4177
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4177
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration, JAAS
>Affects Versions: 2.27.1, 2.28.0
>Reporter: Dries Harnie
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.28.0, 2.29.0
>
>
> In the [Logging chapter of the
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html],
> there is the following section:
> {quote}
> h3. Logging the clients remote address
> It is possible to configure the audit loggers to log the remote address of
> any calling clients either through normal clients or through the console and
> JMX. This is configured by enabling a specific login module in the login
> config file.
> {{org.apache.activemq.artemis.spi.core.security.jaas.AuditLoginModule optional
>debug=false;}}
> {quote}
> This actually accomplishes nothing, for the following reason:
> If you add this line to a block in login.conf and try to login to the broker,
> the Java {{LoginContext}} class will try to instantiate the class mentioned
> above using {{{}Class#newInstance{}}}. However, it is an interface (and has
> been for the past four years). It will thus throw an
> {{InstantiationException}} which is ignored because it is marked as an
> optional module.
> I assume this is a leftover from earlier development, because several other
> login modules _do_ implement the AuditLoginModule interface.
> Suggested fix is to remove this section entirely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4177) Misleading documentation for "Logging the clients remote address"
[
https://issues.apache.org/jira/browse/ARTEMIS-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4177.
---
Resolution: Fixed
> Misleading documentation for "Logging the clients remote address"
> -
>
> Key: ARTEMIS-4177
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4177
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration, JAAS
>Affects Versions: 2.27.1, 2.28.0
>Reporter: Dries Harnie
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.29.0
>
>
> In the [Logging chapter of the
> documentation|https://activemq.apache.org/components/artemis/documentation/latest/logging.html],
> there is the following section:
> {quote}
> h3. Logging the clients remote address
> It is possible to configure the audit loggers to log the remote address of
> any calling clients either through normal clients or through the console and
> JMX. This is configured by enabling a specific login module in the login
> config file.
> {{org.apache.activemq.artemis.spi.core.security.jaas.AuditLoginModule optional
>debug=false;}}
> {quote}
> This actually accomplishes nothing, for the following reason:
> If you add this line to a block in login.conf and try to login to the broker,
> the Java {{LoginContext}} class will try to instantiate the class mentioned
> above using {{{}Class#newInstance{}}}. However, it is an interface (and has
> been for the past four years). It will thus throw an
> {{InstantiationException}} which is ignored because it is marked as an
> optional module.
> I assume this is a leftover from earlier development, because several other
> login modules _do_ implement the AuditLoginModule interface.
> Suggested fix is to remove this section entirely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4251. --- Resolution: Fixed > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4251: - > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4251: Fix Version/s: 2.29.0 > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.29.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4319) Mitigate NPE in paging log statement
[
https://issues.apache.org/jira/browse/ARTEMIS-4319?focusedWorklogId=866760&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866760
]
ASF GitHub Bot logged work on ARTEMIS-4319:
---
Author: ASF GitHub Bot
Created on: 21/Jun/23 13:41
Start Date: 21/Jun/23 13:41
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4512:
URL: https://github.com/apache/activemq-artemis/pull/4512#discussion_r1237023946
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerLogger.java:
##
@@ -1573,13 +1573,13 @@ void slowConsumerDetected(String sessionID,
@LogMessage(id = 224122, value = "Address {} number of messages is under
page limit again, and it should be allowed to page again.", level =
LogMessage.Level.INFO)
void pageFree(SimpleString address);
- @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {},
based on the limitPageBytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
- void pageFullMaxBytes(SimpleString address, long pages, long maxPages, long
limitBytes, long bytes);
+ @LogMessage(id = 224123, value = "Address {} has more pages than allowed.
System currently has {} pages, while the estimated max number of pages is {}
based on the page-limit-bytes ({}) / page-size ({})", level =
LogMessage.Level.WARN)
+ void pageFullMaxBytes(SimpleString address, long pages, Long maxPages, Long
limitBytes, int bytes);
Review Comment:
If the value can be null then having the logger method allow for that seems
reasonable...however...
If the limit value was null, why was it even logging that a non-existent
limit was exceeded? Does this only happen when the value is removed/changed
while already running, or something? Or is this pointing to an actual
behavioural problem somewhere leading to a mis-logging?
Issue Time Tracking
---
Worklog Id: (was: 866760)
Time Spent: 20m (was: 10m)
> Mitigate NPE in paging log statement
>
>
> Key: ARTEMIS-4319
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4319
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From the user's mailing list:
> {quote}
> ...when we remove the limit, as it was too less for our case, we got null
> pointer exception in logs so we are currently forced to use less page limit.
> Since the error here tries to convert to longValue...
> {noformat}
> [org.apache.activemq.artemis.core.server] AMQ25: Sending unexpected
> exception to the client java.lang.NullPointerException: Cannot invoke
> "java.lang.Long.longValue()" because "this.pageLimitBytes" is null
> at
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.checkNumberOfPages(PagingStoreImpl.java:324)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4315) Incorrect validation for page-limit settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4315.
-
Fix Version/s: 2.30.0
Resolution: Fixed
> Incorrect validation for page-limit settings
>
>
> Key: ARTEMIS-4315
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4315
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.30.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From the user's mailing list...
> {quote}
> We started using {{}} starting 2.28.0 version however there
> seems to be some mismatch as to what is in docs and the max value expected
> for this.
> ...
> From the docs, the example snippet has
> {{10G}}, however when we tried to set
> {{2G}} it fails with error.
> {noformat}
> Integer.MAX_VALUE can only support < 2G{noformat}
> so is this an issue with validation alone?
> {noformat}
> java.lang.IllegalArgumentException: AMQ229227: page-limit-bytes must be
> equals to -1 or greater than 0 and less than or equal to Integer.MAX_VALUE
> (actual value: 2147483648)
> at
> org.apache.activemq.artemis.core.config.impl.Validators$11.validate(Validators.java:159)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4315) Incorrect validation for page-limit settings
[
https://issues.apache.org/jira/browse/ARTEMIS-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735714#comment-17735714
]
ASF subversion and git services commented on ARTEMIS-4315:
--
Commit 3db540c61b39043c50233c2a716398fe914c278d in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3db540c61b ]
ARTEMIS-4315 incorrect validation for page-limit settings
> Incorrect validation for page-limit settings
>
>
> Key: ARTEMIS-4315
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4315
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From the user's mailing list...
> {quote}
> We started using {{}} starting 2.28.0 version however there
> seems to be some mismatch as to what is in docs and the max value expected
> for this.
> ...
> From the docs, the example snippet has
> {{10G}}, however when we tried to set
> {{2G}} it fails with error.
> {noformat}
> Integer.MAX_VALUE can only support < 2G{noformat}
> so is this an issue with validation alone?
> {noformat}
> java.lang.IllegalArgumentException: AMQ229227: page-limit-bytes must be
> equals to -1 or greater than 0 and less than or equal to Integer.MAX_VALUE
> (actual value: 2147483648)
> at
> org.apache.activemq.artemis.core.config.impl.Validators$11.validate(Validators.java:159)
> ~[artemis-server-2.28.0.jar:2.28.0]{noformat}{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
