[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901115=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901115
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 05:38
Start Date: 23/Jan/24 05:38
Worklog Time Spent: 10m 
  Work Description: jsmucr commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905325738

   @jbertram Only by **very complicated** workarounds. I need to find out if 
there's an old message in a queue that's been there for a while now, and I'm 
not allowed to use DLQs for that, because it means a manual intervention on the 
broker if processing fails too many times.
   I know this method is heavy but so is our workflow here, which is pretty 
much based on wasting resources in exchange for usability and easy maintenance. 
:-)
   I understand your point of view, I really do, but I also find Artemis to be 
quite an advanced tool all by itself, and that if I slow it down by using a 
method that is heavy on resources, it's entirely my fault as an operator. 
Perhaps a page of documentation would be enough to get rid of responsibility 
here.




Issue Time Tracking
---

Worklog Id: (was: 901115)
Time Spent: 1.5h  (was: 1h 20m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901112=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901112
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 05:33
Start Date: 23/Jan/24 05:33
Worklog Time Spent: 10m 
  Work Description: jsmucr commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462744923


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
   }
}
 
+   protected void notifyScheduledReferencesUpdated() {
+  oldestMessage = null;
+   }
+
+   @Override
+   public MessageReference peekFirstScheduledMessage() {
+  synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+return null;
+ }
+ if (oldestMessage != null) {
+return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+MessageReference ref = scheduledReference.getRef();
+long refTimestamp = ref.getMessage().getTimestamp();
+if (refTimestamp < oldestTimestamp) {
+   oldestTimestamp = refTimestamp;
+   result = ref;
+}
+ }
+ oldestMessage = result;
+ return result;
+  }
+   }

Review Comment:
   The `MessageReferenceComparator` uses scheduled delivery time as a measure, 
so if I'm not mistaken, `scheduledReferences.first()` returns the first message 
to be delivered, not the oldest message in the queue.





Issue Time Tracking
---

Worklog Id: (was: 901112)
Time Spent: 1h 20m  (was: 1h 10m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901106=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901106
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 04:28
Start Date: 23/Jan/24 04:28
Worklog Time Spent: 10m 
  Work Description: jbertram commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905272950

   For awhile I've actually discouraged folks from using the "first message" 
metrics. [I discussed this on the ActiveMQ users 
list](https://lists.apache.org/thread/d79n3kbb28k2v4pm7y0kywb5xpvrmpf4) not 
long ago:
   
   > The `getFirstMessageAge` operation is actually fairly "heavy" and not 
generally recommended. Furthermore, the age of the first message isn't 
meaningful in and of itself in this scenario because if the `consumerCount` is 
0 then by definition no messages can be stuck. A robust stuck-message detection 
mechanism must, at the very least, verify that `consumerCount` > 0. Also, 
instead of using the age of the first message I recommend inspecting 
`messagesAcknowledged` over time. For example, if the `consumerCount` > 0 and 
`messagesAcknowledged` remains unchanged for 60 seconds then messages (or more 
likely *consumers*) may be stuck. If you're using Prometheus then I believe you 
can use a [range vector 
selector](https://prometheus.io/docs/prometheus/latest/querying/basics/#range-vector-selectors)
 for this kind of operation.
   
   At this point I'm against adding "first message" metrics for scheduled 
messages because it will be a relatively "heavy" operation due to the 
`synchronized` block. A lot of JMX monitoring tools will simply poll queue 
MBeans which means this new management method may be invoked *a lot*, 
especially on a broker with lots of queues. Over the last few years we've seen 
an increasing number of deployments with many thousands of queues. This is one 
reason we implemented (and generally recommend using) [pluggable 
metrics](https://activemq.apache.org/components/artemis/documentation/latest/metrics.html#metrics)
 which should provide a lighter footprint than JMX and open the door for easier 
integration with tools that specialize in graphing and alerting (e.g. 
Prometheus & Grafana).
   
   Would it be possible for you to use existing metrics to solve your problem 
rather than implementing this new management method?




Issue Time Tracking
---

Worklog Id: (was: 901106)
Time Spent: 1h 10m  (was: 1h)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (ARTEMIS-4540) Validate MQTT session state data

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-4540.
-
Fix Version/s: 2.32.0
   Resolution: Fixed

> Validate MQTT session state data
> 
>
> Key: ARTEMIS-4540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4540
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
>  __   _
> / \  | |_  ___ __  __(_) _
>/ _ \|  _ \ __|/ _ \  \/  | |/  __/
>   / ___ \ | \/ |_/  __/ |\/| | |\___ \
>  /_/   \_\|   \__\|_|  |_|_|/___ /
>  Apache ActiveMQ Artemis 2.31.0
> 18:58:47,218 INFO  [org.apache.activemq.artemis.integration.bootstrap] 
> AMQ101000: Starting ActiveMQ Artemis Server version 2.31.0
> 18:58:47,288 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging)
> 18:58:47,371 INFO  [org.apache.activemq.artemis.core.server] AMQ221013: Using 
> NIO Journal
> 18:58:47,475 INFO  [org.apache.activemq.artemis.core.server] AMQ221057: 
> Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being 
> defined as 1073741824
> 18:58:47,522 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221034: 
> Waiting indefinitely to obtain live lock
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221035: Live 
> Server Obtained live lock
> 18:58:48,822 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address DLQ supporting [ANYCAST]
> 18:58:48,823 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue DLQ on address DLQ
> 18:58:48,833 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address ExpiryQueue supporting [ANYCAST]
> 18:58:48,834 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue
> 18:58:49,081 WARN  [org.apache.activemq.artemis.core.server] AMQ222080: Error 
> instantiating remoting acceptor 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) 
> ~[?:?]
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.(MQTTStateManager.java:88)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getInstance(MQTTStateManager.java:66)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.(MQTTProtocolManager.java:86)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManagerFactory.createProtocolManager(MQTTProtocolManagerFactory.java:51)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:271)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:217)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3488)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> 

[jira] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=901098=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901098
 ]

ASF GitHub Bot logged work on ARTEMIS-4510:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 03:16
Start Date: 23/Jan/24 03:16
Worklog Time Spent: 10m 
  Work Description: jbertram commented on PR #4681:
URL: 
https://github.com/apache/activemq-artemis/pull/4681#issuecomment-1905221467

   This is an interesting improvement which I think has some merit. However, I 
have two concerns:
   
   - This changes the default behavior of every divert. This may break existing 
users who actually depend on the current behavior. Therefore, this 
functionality should be configurable.
   - This will have a negative impact on performance. _Every_ time a message is 
diverted `checkAutoCreate` will be invoked with a new `QueueConfiguration`. 
This will increase CPU utilization and GC pressure. Perhaps the divert could 
invoke `checkAutoCreate` once when it was deployed and then also during the 
execution of `route` if and only if a transformer was invoked.




Issue Time Tracking
---

Worklog Id: (was: 901098)
Time Spent: 20m  (was: 10m)

> Add auto-create-destination logic to diverts
> 
>
> Key: ARTEMIS-4510
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4510
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Anton Roskvist
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This enables the use of dynamic routing decisions within the transformer by 
> setting the message address. It also covers for a rare problem where if any 
> of the forwarding addresses are removed during runtime, such as from 
> auto-delete, the message would get silently dropped.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (ARTEMIS-4540) Validate MQTT session state data

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-4540:

Summary: Validate MQTT session state data  (was: NullPointerException 
during initialization)

> Validate MQTT session state data
> 
>
> Key: ARTEMIS-4540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4540
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
>  __   _
> / \  | |_  ___ __  __(_) _
>/ _ \|  _ \ __|/ _ \  \/  | |/  __/
>   / ___ \ | \/ |_/  __/ |\/| | |\___ \
>  /_/   \_\|   \__\|_|  |_|_|/___ /
>  Apache ActiveMQ Artemis 2.31.0
> 18:58:47,218 INFO  [org.apache.activemq.artemis.integration.bootstrap] 
> AMQ101000: Starting ActiveMQ Artemis Server version 2.31.0
> 18:58:47,288 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging)
> 18:58:47,371 INFO  [org.apache.activemq.artemis.core.server] AMQ221013: Using 
> NIO Journal
> 18:58:47,475 INFO  [org.apache.activemq.artemis.core.server] AMQ221057: 
> Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being 
> defined as 1073741824
> 18:58:47,522 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221034: 
> Waiting indefinitely to obtain live lock
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221035: Live 
> Server Obtained live lock
> 18:58:48,822 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address DLQ supporting [ANYCAST]
> 18:58:48,823 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue DLQ on address DLQ
> 18:58:48,833 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address ExpiryQueue supporting [ANYCAST]
> 18:58:48,834 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue
> 18:58:49,081 WARN  [org.apache.activemq.artemis.core.server] AMQ222080: Error 
> instantiating remoting acceptor 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) 
> ~[?:?]
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.(MQTTStateManager.java:88)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getInstance(MQTTStateManager.java:66)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.(MQTTProtocolManager.java:86)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManagerFactory.createProtocolManager(MQTTProtocolManagerFactory.java:51)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:271)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:217)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3488)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> 

[jira] [Work logged] (ARTEMIS-4540) NullPointerException during initialization

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4540?focusedWorklogId=901095=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901095
 ]

ASF GitHub Bot logged work on ARTEMIS-4540:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 02:58
Start Date: 23/Jan/24 02:58
Worklog Time Spent: 10m 
  Work Description: jbertram merged PR #4725:
URL: https://github.com/apache/activemq-artemis/pull/4725




Issue Time Tracking
---

Worklog Id: (was: 901095)
Time Spent: 50m  (was: 40m)

> NullPointerException during initialization
> --
>
> Key: ARTEMIS-4540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4540
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
>  __   _
> / \  | |_  ___ __  __(_) _
>/ _ \|  _ \ __|/ _ \  \/  | |/  __/
>   / ___ \ | \/ |_/  __/ |\/| | |\___ \
>  /_/   \_\|   \__\|_|  |_|_|/___ /
>  Apache ActiveMQ Artemis 2.31.0
> 18:58:47,218 INFO  [org.apache.activemq.artemis.integration.bootstrap] 
> AMQ101000: Starting ActiveMQ Artemis Server version 2.31.0
> 18:58:47,288 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging)
> 18:58:47,371 INFO  [org.apache.activemq.artemis.core.server] AMQ221013: Using 
> NIO Journal
> 18:58:47,475 INFO  [org.apache.activemq.artemis.core.server] AMQ221057: 
> Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being 
> defined as 1073741824
> 18:58:47,522 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221034: 
> Waiting indefinitely to obtain live lock
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221035: Live 
> Server Obtained live lock
> 18:58:48,822 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address DLQ supporting [ANYCAST]
> 18:58:48,823 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue DLQ on address DLQ
> 18:58:48,833 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address ExpiryQueue supporting [ANYCAST]
> 18:58:48,834 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue
> 18:58:49,081 WARN  [org.apache.activemq.artemis.core.server] AMQ222080: Error 
> instantiating remoting acceptor 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) 
> ~[?:?]
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.(MQTTStateManager.java:88)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getInstance(MQTTStateManager.java:66)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.(MQTTProtocolManager.java:86)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManagerFactory.createProtocolManager(MQTTProtocolManagerFactory.java:51)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:271)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 

[jira] [Commented] (ARTEMIS-4540) NullPointerException during initialization

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809716#comment-17809716
 ] 

ASF subversion and git services commented on ARTEMIS-4540:
--

Commit 44ceeff63cd98062f1a0bcd10b58f7498e65588c in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=44ceeff63c ]

ARTEMIS-4540 validate MQTT session state data


> NullPointerException during initialization
> --
>
> Key: ARTEMIS-4540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4540
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
>  __   _
> / \  | |_  ___ __  __(_) _
>/ _ \|  _ \ __|/ _ \  \/  | |/  __/
>   / ___ \ | \/ |_/  __/ |\/| | |\___ \
>  /_/   \_\|   \__\|_|  |_|_|/___ /
>  Apache ActiveMQ Artemis 2.31.0
> 18:58:47,218 INFO  [org.apache.activemq.artemis.integration.bootstrap] 
> AMQ101000: Starting ActiveMQ Artemis Server version 2.31.0
> 18:58:47,288 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging)
> 18:58:47,371 INFO  [org.apache.activemq.artemis.core.server] AMQ221013: Using 
> NIO Journal
> 18:58:47,475 INFO  [org.apache.activemq.artemis.core.server] AMQ221057: 
> Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being 
> defined as 1073741824
> 18:58:47,522 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221034: 
> Waiting indefinitely to obtain live lock
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221035: Live 
> Server Obtained live lock
> 18:58:48,822 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address DLQ supporting [ANYCAST]
> 18:58:48,823 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue DLQ on address DLQ
> 18:58:48,833 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address ExpiryQueue supporting [ANYCAST]
> 18:58:48,834 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue
> 18:58:49,081 WARN  [org.apache.activemq.artemis.core.server] AMQ222080: Error 
> instantiating remoting acceptor 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) 
> ~[?:?]
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.(MQTTStateManager.java:88)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getInstance(MQTTStateManager.java:66)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.(MQTTProtocolManager.java:86)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManagerFactory.createProtocolManager(MQTTProtocolManagerFactory.java:51)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:271)
>  [artemis-server-2.31.0.jar:2.31.0]
> at 
> 

[jira] [Updated] (ARTEMIS-4542) Improve MQTT state storage

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-4542:

Summary: Improve MQTT state storage  (was: "Error disconnecting client" 
after connecting and disconnecting a few times)

> Improve MQTT state storage
> --
>
> Key: ARTEMIS-4542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4542
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> During some local tests which involved manually disconnecting and 
> reconnecting one MQTT client, at one point the ability to (re)connect was 
> lost, while the MQTT server kept printing the following message:
> {noformat}
> 2023-12-19 16:09:35,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834002: Error processing 
> control packet: 
> MqttConnectMessage[fixedHeader=MqttFixedHeader[messageType=CONNECT, 
> isDup=false, qosLevel=AT_MOST_ONCE, isRetain=false, remainingLength=81], 
> variableHeader=MqttConnectVariableHeader[name=MQTT, version=5, 
> hasUserName=true, hasPassword=true, isWillRetain=false, isWillFlag=false, 
> isCleanSession=false, keepAliveTimeSeconds=60], 
> payload=MqttConnectPayload[clientIdentifier=99778aca-86a8-4b3e-84b9-74778c77e0e1,
>  willTopic=null, willMessage=null, userName=artemis, password=[...]]]
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getSessionState(MQTTStateManager.java:130)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.getSessionState(MQTTConnectionManager.java:206)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.connect(MQTTConnectionManager.java:71)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.handleConnect(MQTTProtocolHandler.java:267)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:159)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>  ~[artemis-commons-2.31.0.jar:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  [?:?]
>  at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.31.0.jar:?]
> 2023-12-19 16:09:40,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834001: Error 
> disconnecting client.
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.removeSubscriptions(MQTTSubscriptionManager.java:291)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.clean(MQTTSubscriptionManager.java:368)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.clean(MQTTSession.java:233)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.stop(MQTTSession.java:136)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:186)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.disconnect(MQTTProtocolHandler.java:282)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:183)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> 

[jira] [Resolved] (ARTEMIS-4542) Improve MQTT state storage

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-4542.
-
Fix Version/s: 2.32.0
   Resolution: Fixed

> Improve MQTT state storage
> --
>
> Key: ARTEMIS-4542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4542
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> During some local tests which involved manually disconnecting and 
> reconnecting one MQTT client, at one point the ability to (re)connect was 
> lost, while the MQTT server kept printing the following message:
> {noformat}
> 2023-12-19 16:09:35,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834002: Error processing 
> control packet: 
> MqttConnectMessage[fixedHeader=MqttFixedHeader[messageType=CONNECT, 
> isDup=false, qosLevel=AT_MOST_ONCE, isRetain=false, remainingLength=81], 
> variableHeader=MqttConnectVariableHeader[name=MQTT, version=5, 
> hasUserName=true, hasPassword=true, isWillRetain=false, isWillFlag=false, 
> isCleanSession=false, keepAliveTimeSeconds=60], 
> payload=MqttConnectPayload[clientIdentifier=99778aca-86a8-4b3e-84b9-74778c77e0e1,
>  willTopic=null, willMessage=null, userName=artemis, password=[...]]]
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getSessionState(MQTTStateManager.java:130)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.getSessionState(MQTTConnectionManager.java:206)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.connect(MQTTConnectionManager.java:71)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.handleConnect(MQTTProtocolHandler.java:267)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:159)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>  ~[artemis-commons-2.31.0.jar:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  [?:?]
>  at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.31.0.jar:?]
> 2023-12-19 16:09:40,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834001: Error 
> disconnecting client.
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.removeSubscriptions(MQTTSubscriptionManager.java:291)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.clean(MQTTSubscriptionManager.java:368)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.clean(MQTTSession.java:233)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.stop(MQTTSession.java:136)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:186)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.disconnect(MQTTProtocolHandler.java:282)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:183)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> 

[jira] [Commented] (ARTEMIS-4542) "Error disconnecting client" after connecting and disconnecting a few times

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809702#comment-17809702
 ] 

ASF subversion and git services commented on ARTEMIS-4542:
--

Commit 019fc86138239cc34e84dd4c90326e6615e75e6b in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=019fc86138 ]

ARTEMIS-4542 improve MQTT state storage

This commit:

 - Eliminates MQTT session storage on every successful connection.
   Instead data is only written when subsriptions are created or
   destroyed.
 - Adds a configuration property for the storage timeout.
 - Updates the documentation with relevant information.
 - Refactors a few bits of code to eliminate unnecessary variables, etc.


> "Error disconnecting client" after connecting and disconnecting a few times
> ---
>
> Key: ARTEMIS-4542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4542
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> During some local tests which involved manually disconnecting and 
> reconnecting one MQTT client, at one point the ability to (re)connect was 
> lost, while the MQTT server kept printing the following message:
> {noformat}
> 2023-12-19 16:09:35,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834002: Error processing 
> control packet: 
> MqttConnectMessage[fixedHeader=MqttFixedHeader[messageType=CONNECT, 
> isDup=false, qosLevel=AT_MOST_ONCE, isRetain=false, remainingLength=81], 
> variableHeader=MqttConnectVariableHeader[name=MQTT, version=5, 
> hasUserName=true, hasPassword=true, isWillRetain=false, isWillFlag=false, 
> isCleanSession=false, keepAliveTimeSeconds=60], 
> payload=MqttConnectPayload[clientIdentifier=99778aca-86a8-4b3e-84b9-74778c77e0e1,
>  willTopic=null, willMessage=null, userName=artemis, password=[...]]]
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getSessionState(MQTTStateManager.java:130)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.getSessionState(MQTTConnectionManager.java:206)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.connect(MQTTConnectionManager.java:71)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.handleConnect(MQTTProtocolHandler.java:267)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:159)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>  ~[artemis-commons-2.31.0.jar:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  [?:?]
>  at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.31.0.jar:?]
> 2023-12-19 16:09:40,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834001: Error 
> disconnecting client.
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.removeSubscriptions(MQTTSubscriptionManager.java:291)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.clean(MQTTSubscriptionManager.java:368)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.clean(MQTTSession.java:233)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.stop(MQTTSession.java:136)
>  

[jira] [Work logged] (ARTEMIS-4542) "Error disconnecting client" after connecting and disconnecting a few times

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4542?focusedWorklogId=901089=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901089
 ]

ASF GitHub Bot logged work on ARTEMIS-4542:
---

Author: ASF GitHub Bot
Created on: 23/Jan/24 01:58
Start Date: 23/Jan/24 01:58
Worklog Time Spent: 10m 
  Work Description: jbertram merged PR #4724:
URL: https://github.com/apache/activemq-artemis/pull/4724




Issue Time Tracking
---

Worklog Id: (was: 901089)
Time Spent: 40m  (was: 0.5h)

> "Error disconnecting client" after connecting and disconnecting a few times
> ---
>
> Key: ARTEMIS-4542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4542
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> During some local tests which involved manually disconnecting and 
> reconnecting one MQTT client, at one point the ability to (re)connect was 
> lost, while the MQTT server kept printing the following message:
> {noformat}
> 2023-12-19 16:09:35,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834002: Error processing 
> control packet: 
> MqttConnectMessage[fixedHeader=MqttFixedHeader[messageType=CONNECT, 
> isDup=false, qosLevel=AT_MOST_ONCE, isRetain=false, remainingLength=81], 
> variableHeader=MqttConnectVariableHeader[name=MQTT, version=5, 
> hasUserName=true, hasPassword=true, isWillRetain=false, isWillFlag=false, 
> isCleanSession=false, keepAliveTimeSeconds=60], 
> payload=MqttConnectPayload[clientIdentifier=99778aca-86a8-4b3e-84b9-74778c77e0e1,
>  willTopic=null, willMessage=null, userName=artemis, password=[...]]]
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getSessionState(MQTTStateManager.java:130)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.getSessionState(MQTTConnectionManager.java:206)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.connect(MQTTConnectionManager.java:71)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.handleConnect(MQTTProtocolHandler.java:267)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:159)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>  ~[artemis-commons-2.31.0.jar:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  [?:?]
>  at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.31.0.jar:?]
> 2023-12-19 16:09:40,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834001: Error 
> disconnecting client.
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.removeSubscriptions(MQTTSubscriptionManager.java:291)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.clean(MQTTSubscriptionManager.java:368)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.clean(MQTTSession.java:233)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.stop(MQTTSession.java:136)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:186)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> 

[jira] [Commented] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809663#comment-17809663
 ] 

ASF subversion and git services commented on ARTEMIS-4185:
--

Commit f56595b89b5b32ecd928a2c0d2c76410879daaed in activemq-artemis's branch 
refs/heads/main from a181321
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f56595b89b ]

ARTEMIS-4185 - Revision on sending already compressed messages


> 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] [Commented] (ARTEMIS-4581) NullPointer exception on Queue scan Init

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809662#comment-17809662
 ] 

ASF subversion and git services commented on ARTEMIS-4581:
--

Commit fbfe81eb4d5f3c3c625a9beaa9647b837ed6058a in activemq-artemis's branch 
refs/heads/main from Pavel Perikov
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fbfe81eb4d ]

ARTEMIS-4581 fix NPE crash in PostOfficeImpl


> NullPointer exception on Queue scan Init
> 
>
> Key: ARTEMIS-4581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4581
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Clebert Suconic
>Priority: Major
> Fix For: 2.32.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (ARTEMIS-4581) NullPointer exception on Queue scan Init

[Clebert Suconic (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clebert Suconic updated ARTEMIS-4581:
-
Issue Type: Bug  (was: Improvement)

> NullPointer exception on Queue scan Init
> 
>
> Key: ARTEMIS-4581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4581
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.2
>Reporter: Clebert Suconic
>Priority: Major
> Fix For: 2.32.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (ARTEMIS-4581) NullPointer exception on Queue scan Init

[Clebert Suconic (Jira)]

Clebert Suconic created ARTEMIS-4581:


 Summary: NullPointer exception on Queue scan Init
 Key: ARTEMIS-4581
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4581
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Affects Versions: 2.31.2
Reporter: Clebert Suconic
 Fix For: 2.32.0






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4559) Refactor HA docs & code/module naming

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4559?focusedWorklogId=901047=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901047
 ]

ASF GitHub Bot logged work on ARTEMIS-4559:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:51
Start Date: 22/Jan/24 20:51
Worklog Time Spent: 10m 
  Work Description: jbertram commented on PR #4735:
URL: 
https://github.com/apache/activemq-artemis/pull/4735#issuecomment-1904785918

   @clebertsuconic, that's a fair point. I updated the Jira and commit message 
to reflect this.




Issue Time Tracking
---

Worklog Id: (was: 901047)
Time Spent: 40m  (was: 0.5h)

> Refactor HA docs & code/module naming
> -
>
> Key: ARTEMIS-4559
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4559
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Over the years the HA docs have gotten a bit confusing. They need to be 
> refreshed and clarified in light of new features, etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (ARTEMIS-4559) Refactor HA docs & code/module naming

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-4559:

Summary: Refactor HA docs & code/module naming  (was: Refactor HA docs)

> Refactor HA docs & code/module naming
> -
>
> Key: ARTEMIS-4559
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4559
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Over the years the HA docs have gotten a bit confusing. They need to be 
> refreshed and clarified in light of new features, etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901044=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901044
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:37
Start Date: 22/Jan/24 20:37
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462388462


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt5/spec/controlpackets/PublishTests.java:
##
@@ -653,6 +654,10 @@ public void messageArrived(String topic, MqttMessage 
message) throws Exception {
   consumer.close();
}
 
+   private Queue getRetainedMessageQueue(String TOPIC) {
+  return 
server.locateQueue(MQTTUtil.convertMqttTopicFilterToCore(MQTTUtil.MQTT_RETAIN_ADDRESS_PREFIX,
 TOPIC, server.getConfiguration().getWildcardConfiguration()));
+   }

Review Comment:
   BTW, I fixed the parameter name.





Issue Time Tracking
---

Worklog Id: (was: 901044)
Time Spent: 1h 40m  (was: 1.5h)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901043=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901043
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:34
Start Date: 22/Jan/24 20:34
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462385712


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt5/spec/controlpackets/PublishTests.java:
##
@@ -269,15 +270,15 @@ public void testRetainFlagWithEmptyMessage() throws 
Exception {
   // send first retained message
   producer.publish(TOPIC, "retain1".getBytes(), 2, true);
 
-  Wait.assertTrue(() -> 
server.locateQueue(MQTTUtil.convertMqttTopicFilterToCore(MQTTUtil.MQTT_RETAIN_ADDRESS_PREFIX,
 TOPIC, MQTTUtil.MQTT_WILDCARD)).getMessageCount() == 1, 2000, 100);
+  Wait.assertTrue(() -> getRetainedMessageQueue(TOPIC).getMessageCount() 
== 1, 2000, 100);

Review Comment:
   Fixed.





Issue Time Tracking
---

Worklog Id: (was: 901043)
Time Spent: 1.5h  (was: 1h 20m)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901042=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901042
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:34
Start Date: 22/Jan/24 20:34
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462385481


##
docs/user-manual/versions.adoc:
##
@@ -31,6 +31,13 @@ These settings are now no longer required.
 +
 Configure `defaultMqttSessionExpiryInterval` instead.
 
+* Due to https://issues.apache.org/jira/browse/ARTEMIS-4532[ARTEMIS-4532] the 
names of addresses and queues related to MQTT topics and subscriptions 
respectively may change. This will only impact you:
++
+  . If the broker is configured to use a xref:wildcard-syntax.adoc[wildcard 
syntax] which doesn't match the xref:mqtt.adoc#wildcard-syntax[MQTT wildcard 
syntax].
+  . If you are using characters from the broker's wildcard syntax in your MQTT 
topic names or topic filters.
++
+In this case the characters from the broker's wildcard syntax that do not 
match the characters in the MQTT wildcard syntax will be escaped with a 
backslash (i.e. `\`).

Review Comment:
   Updated.





Issue Time Tracking
---

Worklog Id: (was: 901042)
Time Spent: 1h 20m  (was: 1h 10m)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901041=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901041
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:34
Start Date: 22/Jan/24 20:34
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462385165


##
artemis-server/src/test/java/org/apache/activemq/artemis/core/config/WildcardConfigurationTest.java:
##
@@ -0,0 +1,40 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.config;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+public class WildcardConfigurationTest extends Assert {
+
+   public static final WildcardConfiguration MQTT_WILDCARD = new 
WildcardConfiguration().setDelimiter('/').setAnyWords('#').setSingleWord('+');
+   public static final WildcardConfiguration DEFAULT_WILDCARD = new 
WildcardConfiguration();

Review Comment:
   Done.





Issue Time Tracking
---

Worklog Id: (was: 901041)
Time Spent: 1h 10m  (was: 1h)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901040=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901040
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:33
Start Date: 22/Jan/24 20:33
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462384875


##
docs/user-manual/versions.adoc:
##
@@ -31,6 +31,13 @@ These settings are now no longer required.
 +
 Configure `defaultMqttSessionExpiryInterval` instead.
 
+* Due to https://issues.apache.org/jira/browse/ARTEMIS-4532[ARTEMIS-4532] the 
names of addresses and queues related to MQTT topics and subscriptions 
respectively may change. This will only impact you:
++
+  . If the broker is configured to use a xref:wildcard-syntax.adoc[wildcard 
syntax] which doesn't match the xref:mqtt.adoc#wildcard-syntax[MQTT wildcard 
syntax].
+  . If you are using characters from the broker's wildcard syntax in your MQTT 
topic names or topic filters.

Review Comment:
   Updated.



##
artemis-server/src/test/java/org/apache/activemq/artemis/core/config/WildcardConfigurationTest.java:
##
@@ -0,0 +1,40 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.config;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+public class WildcardConfigurationTest extends Assert {

Review Comment:
   I added a new test.





Issue Time Tracking
---

Worklog Id: (was: 901040)
Time Spent: 1h  (was: 50m)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4542) "Error disconnecting client" after connecting and disconnecting a few times

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4542?focusedWorklogId=901039=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901039
 ]

ASF GitHub Bot logged work on ARTEMIS-4542:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:13
Start Date: 22/Jan/24 20:13
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4724:
URL: 
https://github.com/apache/activemq-artemis/pull/4724#issuecomment-1904732301

   LGTM.. as long as tests are good




Issue Time Tracking
---

Worklog Id: (was: 901039)
Time Spent: 0.5h  (was: 20m)

> "Error disconnecting client" after connecting and disconnecting a few times
> ---
>
> Key: ARTEMIS-4542
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4542
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> During some local tests which involved manually disconnecting and 
> reconnecting one MQTT client, at one point the ability to (re)connect was 
> lost, while the MQTT server kept printing the following message:
> {noformat}
> 2023-12-19 16:09:35,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834002: Error processing 
> control packet: 
> MqttConnectMessage[fixedHeader=MqttFixedHeader[messageType=CONNECT, 
> isDup=false, qosLevel=AT_MOST_ONCE, isRetain=false, remainingLength=81], 
> variableHeader=MqttConnectVariableHeader[name=MQTT, version=5, 
> hasUserName=true, hasPassword=true, isWillRetain=false, isWillFlag=false, 
> isCleanSession=false, keepAliveTimeSeconds=60], 
> payload=MqttConnectPayload[clientIdentifier=99778aca-86a8-4b3e-84b9-74778c77e0e1,
>  willTopic=null, willMessage=null, userName=artemis, password=[...]]]
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getSessionState(MQTTStateManager.java:130)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.getSessionState(MQTTConnectionManager.java:206)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.connect(MQTTConnectionManager.java:71)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.handleConnect(MQTTProtocolHandler.java:267)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolHandler.act(MQTTProtocolHandler.java:159)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32) 
> ~[artemis-commons-2.31.0.jar:?]
>  at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
>  ~[artemis-commons-2.31.0.jar:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>  [?:?]
>  at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.31.0.jar:?]
> 2023-12-19 16:09:40,105 ERROR 
> [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834001: Error 
> disconnecting client.
> java.lang.IllegalStateException: AMQ85: Unable to store MQTT state within 
> given timeout: 5000ms
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.storeSessionState(MQTTStateManager.java:177)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.removeSubscriptions(MQTTSubscriptionManager.java:291)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSubscriptionManager.clean(MQTTSubscriptionManager.java:368)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.clean(MQTTSession.java:233)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession.stop(MQTTSession.java:136)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
>  at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:186)
>  

[jira] [Work logged] (ARTEMIS-4540) NullPointerException during initialization

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4540?focusedWorklogId=901038=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901038
 ]

ASF GitHub Bot logged work on ARTEMIS-4540:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:12
Start Date: 22/Jan/24 20:12
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4725:
URL: 
https://github.com/apache/activemq-artemis/pull/4725#issuecomment-1904730951

   LGTM ... as long as tests (whole test suite) are good...




Issue Time Tracking
---

Worklog Id: (was: 901038)
Time Spent: 40m  (was: 0.5h)

> NullPointerException during initialization
> --
>
> Key: ARTEMIS-4540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4540
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.31.0
>Reporter: Daniel Martin
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
>  __   _
> / \  | |_  ___ __  __(_) _
>/ _ \|  _ \ __|/ _ \  \/  | |/  __/
>   / ___ \ | \/ |_/  __/ |\/| | |\___ \
>  /_/   \_\|   \__\|_|  |_|_|/___ /
>  Apache ActiveMQ Artemis 2.31.0
> 18:58:47,218 INFO  [org.apache.activemq.artemis.integration.bootstrap] 
> AMQ101000: Starting ActiveMQ Artemis Server version 2.31.0
> 18:58:47,288 INFO  [org.apache.activemq.artemis.core.server] AMQ221000: live 
> Message Broker is starting with configuration Broker Configuration 
> (clustered=false,journalDirectory=data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/large-messages,pagingDirectory=data/paging)
> 18:58:47,371 INFO  [org.apache.activemq.artemis.core.server] AMQ221013: Using 
> NIO Journal
> 18:58:47,475 INFO  [org.apache.activemq.artemis.core.server] AMQ221057: 
> Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being 
> defined as 1073741824
> 18:58:47,522 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: 
> AMQP
> 18:58:47,524 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-hornetq-protocol]. Adding protocol support 
> for: HORNETQ
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-mqtt-protocol]. Adding protocol support for: 
> MQTT
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-openwire-protocol]. Adding protocol support 
> for: OPENWIRE
> 18:58:47,528 INFO  [org.apache.activemq.artemis.core.server] AMQ221043: 
> Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: 
> STOMP
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221034: 
> Waiting indefinitely to obtain live lock
> 18:58:47,664 INFO  [org.apache.activemq.artemis.core.server] AMQ221035: Live 
> Server Obtained live lock
> 18:58:48,822 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address DLQ supporting [ANYCAST]
> 18:58:48,823 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue DLQ on address DLQ
> 18:58:48,833 INFO  [org.apache.activemq.artemis.core.server] AMQ221080: 
> Deploying address ExpiryQueue supporting [ANYCAST]
> 18:58:48,834 INFO  [org.apache.activemq.artemis.core.server] AMQ221003: 
> Deploying ANYCAST queue ExpiryQueue on address ExpiryQueue
> 18:58:49,081 WARN  [org.apache.activemq.artemis.core.server] AMQ222080: Error 
> instantiating remoting acceptor 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory
> java.lang.NullPointerException: null
> at 
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) 
> ~[?:?]
> at 
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.(MQTTStateManager.java:88)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTStateManager.getInstance(MQTTStateManager.java:66)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.(MQTTProtocolManager.java:86)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManagerFactory.createProtocolManager(MQTTProtocolManagerFactory.java:51)
>  ~[artemis-mqtt-protocol-2.31.0.jar:2.31.0]
> at 
> 

[jira] [Work logged] (ARTEMIS-4559) Refactor HA docs

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4559?focusedWorklogId=901037=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901037
 ]

ASF GitHub Bot logged work on ARTEMIS-4559:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:12
Start Date: 22/Jan/24 20:12
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4735:
URL: 
https://github.com/apache/activemq-artemis/pull/4735#issuecomment-1904730094

   This is a big beyond refactoring just docs, right? you're also renaming the 
package and project name?
   
   
   not complaining about the change.. just noticing it's a bit more than just 
doc changes?




Issue Time Tracking
---

Worklog Id: (was: 901037)
Time Spent: 0.5h  (was: 20m)

> Refactor HA docs
> 
>
> Key: ARTEMIS-4559
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4559
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Over the years the HA docs have gotten a bit confusing. They need to be 
> refreshed and clarified in light of new features, etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4576) ServerSessionImpl#updateProducerMetrics access large messages after being routed

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4576?focusedWorklogId=901034=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901034
 ]

ASF GitHub Bot logged work on ARTEMIS-4576:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:09
Start Date: 22/Jan/24 20:09
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4749:
URL: 
https://github.com/apache/activemq-artemis/pull/4749#issuecomment-1904726062

   I pushed this directly... hence I'm closing this PR as I already "merged it"




Issue Time Tracking
---

Worklog Id: (was: 901034)
Time Spent: 1h 50m  (was: 1h 40m)

> ServerSessionImpl#updateProducerMetrics access large messages after being 
> routed
> 
>
> Key: ARTEMIS-4576
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4576
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> ServerSessionImpl#updateProducerMetrics method is being called after a 
> message is routed. If the message is a large message, it can be acked quickly 
> and it's backing file will be closed before the method is being called.
> This bug causes random failure in test 
> org.apache.activemq.artemis.tests.integration.paging.MessagesExpiredPagingTest#testSendReceiveCORELarge



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4576) ServerSessionImpl#updateProducerMetrics access large messages after being routed

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4576?focusedWorklogId=901033=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901033
 ]

ASF GitHub Bot logged work on ARTEMIS-4576:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:09
Start Date: 22/Jan/24 20:09
Worklog Time Spent: 10m 
  Work Description: clebertsuconic closed pull request #4749: ARTEMIS-4576 
ServerSessionImpl#updateProducerMetrics access large messages after being routed
URL: https://github.com/apache/activemq-artemis/pull/4749




Issue Time Tracking
---

Worklog Id: (was: 901033)
Time Spent: 1h 40m  (was: 1.5h)

> ServerSessionImpl#updateProducerMetrics access large messages after being 
> routed
> 
>
> Key: ARTEMIS-4576
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4576
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> ServerSessionImpl#updateProducerMetrics method is being called after a 
> message is routed. If the message is a large message, it can be acked quickly 
> and it's backing file will be closed before the method is being called.
> This bug causes random failure in test 
> org.apache.activemq.artemis.tests.integration.paging.MessagesExpiredPagingTest#testSendReceiveCORELarge



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (ARTEMIS-4576) ServerSessionImpl#updateProducerMetrics access large messages after being routed

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809627#comment-17809627
 ] 

ASF subversion and git services commented on ARTEMIS-4576:
--

Commit 6f6c5723d50b179860319d380ab759ea1d65620a in activemq-artemis's branch 
refs/heads/main from Howard Gao
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=6f6c5723d5 ]

ARTEMIS-4576 ServerSessionImpl#updateProducerMetrics access large messages 
after being routed


> ServerSessionImpl#updateProducerMetrics access large messages after being 
> routed
> 
>
> Key: ARTEMIS-4576
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4576
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> ServerSessionImpl#updateProducerMetrics method is being called after a 
> message is routed. If the message is a large message, it can be acked quickly 
> and it's backing file will be closed before the method is being called.
> This bug causes random failure in test 
> org.apache.activemq.artemis.tests.integration.paging.MessagesExpiredPagingTest#testSendReceiveCORELarge



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4576) ServerSessionImpl#updateProducerMetrics access large messages after being routed

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4576?focusedWorklogId=901032=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901032
 ]

ASF GitHub Bot logged work on ARTEMIS-4576:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:05
Start Date: 22/Jan/24 20:05
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4749:
URL: 
https://github.com/apache/activemq-artemis/pull/4749#issuecomment-1904720169

   Ohhh.. I see now... 




Issue Time Tracking
---

Worklog Id: (was: 901032)
Time Spent: 1.5h  (was: 1h 20m)

> ServerSessionImpl#updateProducerMetrics access large messages after being 
> routed
> 
>
> Key: ARTEMIS-4576
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4576
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> ServerSessionImpl#updateProducerMetrics method is being called after a 
> message is routed. If the message is a large message, it can be acked quickly 
> and it's backing file will be closed before the method is being called.
> This bug causes random failure in test 
> org.apache.activemq.artemis.tests.integration.paging.MessagesExpiredPagingTest#testSendReceiveCORELarge



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-3831) Scale-down fails when using same discovery-group used by Broker cluster connection

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3831?focusedWorklogId=901031=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901031
 ]

ASF GitHub Bot logged work on ARTEMIS-3831:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:02
Start Date: 22/Jan/24 20:02
Worklog Time Spent: 10m 
  Work Description: clebertsuconic merged PR #4739:
URL: https://github.com/apache/activemq-artemis/pull/4739




Issue Time Tracking
---

Worklog Id: (was: 901031)
Time Spent: 20m  (was: 10m)

> Scale-down fails when using same discovery-group used by Broker cluster 
> connection
> --
>
> Key: ARTEMIS-3831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3831
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.19.1, 2.31.0
>Reporter: Apache Dev
>Assignee: Justin Bertram
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using 2 Live brokers in cluster.
> Both having the following HA Policy:
> {code}
> 
> 
> 
> true
>  discovery-group-name="activemq-discovery-group"/>
> 
> 
> 
> {code}
> where "activemq-discovery-group" is using JGroups TCPPING:
> {code}
> 
> 
> ...
> ...
> 1
> 
> 
> {code}
> and it is used by the cluster of 2 brokers:
> {code}
> 
> 
> netty-connector
> 5000
> true
> OFF
> 1
>  discovery-group-name="activemq-discovery-group"/>
> 
> 
> {code}
> Issue is that when shutdown happens, scale-down fails:
> {code}
> org.apache.activemq.artemis.core.server  W AMQ222181: 
> Unable to scaleDown messages
> ActiveMQInternalErrorException[errorType=INTERNAL_ERROR 
> message=AMQ219004: Failed to initialise session factory]
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize(ServerLocatorImpl.java:272)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:655)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:554)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:533)
> at 
> org.apache.activemq.artemis.core.server.LiveNodeLocator.connectToCluster(LiveNodeLocator.java:85)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.connectToScaleDownTarget(LiveOnlyActivation.java:146)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.freezeConnections(LiveOnlyActivation.java:114)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.freezeConnections(ActiveMQServerImpl.java:1468)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1250)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1166)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1150)
> ...
> Caused by: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR 
> message=channel is closed]
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.startDiscovery(ServerLocatorImpl.java:286)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize(ServerLocatorImpl.java:268)
> ... 44 more
> Caused by: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:957)
> at org.jgroups.JChannel._preConnect(JChannel.java:548)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at 
> org.apache.activemq.artemis.api.core.jgroups.JChannelWrapper.connect(JChannelWrapper.java:126)
> at 
> org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:113)
> at 
> org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:91)
> at 
> org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:111)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.startDiscovery(ServerLocatorImpl.java:284)
> ... 45 more
> {code}
> JGroups channel used by scale-down is probably the 

[jira] [Commented] (ARTEMIS-3831) Scale-down fails when using same discovery-group used by Broker cluster connection

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809624#comment-17809624
 ] 

ASF subversion and git services commented on ARTEMIS-3831:
--

Commit 3dd50f8ff14116234909ad2e275515b2b83971b5 in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3dd50f8ff1 ]

ARTEMIS-3831 scale-down w/jgroups fails if using same dg as cluster-connection

If both scale-down and cluster-connection are using the same JGroups
discovery-group then when the cluster-connection stops it will close the
underlying org.jgroups.JChannel and when the scale-down process tries to
use it to find a server it will fail.

This commit ensures that the JGroupsBroadcastEndpoint implementation of
BroadcastEndpoint#openClient initializes the channel if it has been
closed.


> Scale-down fails when using same discovery-group used by Broker cluster 
> connection
> --
>
> Key: ARTEMIS-3831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3831
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.19.1, 2.31.0
>Reporter: Apache Dev
>Assignee: Justin Bertram
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using 2 Live brokers in cluster.
> Both having the following HA Policy:
> {code}
> 
> 
> 
> true
>  discovery-group-name="activemq-discovery-group"/>
> 
> 
> 
> {code}
> where "activemq-discovery-group" is using JGroups TCPPING:
> {code}
> 
> 
> ...
> ...
> 1
> 
> 
> {code}
> and it is used by the cluster of 2 brokers:
> {code}
> 
> 
> netty-connector
> 5000
> true
> OFF
> 1
>  discovery-group-name="activemq-discovery-group"/>
> 
> 
> {code}
> Issue is that when shutdown happens, scale-down fails:
> {code}
> org.apache.activemq.artemis.core.server  W AMQ222181: 
> Unable to scaleDown messages
> ActiveMQInternalErrorException[errorType=INTERNAL_ERROR 
> message=AMQ219004: Failed to initialise session factory]
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize(ServerLocatorImpl.java:272)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:655)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:554)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:533)
> at 
> org.apache.activemq.artemis.core.server.LiveNodeLocator.connectToCluster(LiveNodeLocator.java:85)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.connectToScaleDownTarget(LiveOnlyActivation.java:146)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.freezeConnections(LiveOnlyActivation.java:114)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.freezeConnections(ActiveMQServerImpl.java:1468)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1250)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1166)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1150)
> ...
> Caused by: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR 
> message=channel is closed]
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.startDiscovery(ServerLocatorImpl.java:286)
> at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize(ServerLocatorImpl.java:268)
> ... 44 more
> Caused by: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:957)
> at org.jgroups.JChannel._preConnect(JChannel.java:548)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at 
> org.apache.activemq.artemis.api.core.jgroups.JChannelWrapper.connect(JChannelWrapper.java:126)
> at 
> org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:113)
> at 
> 

[jira] [Work logged] (ARTEMIS-4576) ServerSessionImpl#updateProducerMetrics access large messages after being routed

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4576?focusedWorklogId=901030=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901030
 ]

ASF GitHub Bot logged work on ARTEMIS-4576:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:00
Start Date: 22/Jan/24 20:00
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4749:
URL: 
https://github.com/apache/activemq-artemis/pull/4749#issuecomment-1904713729

   @howardgao I don't actually understand what's being fixed.. it seems the 
same semantic.. replacing 6 by half dozen?
   
   
   Perhaps you meant to check this for AMQP, in which case you would have to 
also check for AMQPLargeServerMessage... or maybe add another method to an 
upper level?
   
   
   
   if you actually create a test to validate what's wrong, it would be check 
the right fix.




Issue Time Tracking
---

Worklog Id: (was: 901030)
Time Spent: 1h 20m  (was: 1h 10m)

> ServerSessionImpl#updateProducerMetrics access large messages after being 
> routed
> 
>
> Key: ARTEMIS-4576
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4576
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> ServerSessionImpl#updateProducerMetrics method is being called after a 
> message is routed. If the message is a large message, it can be acked quickly 
> and it's backing file will be closed before the method is being called.
> This bug causes random failure in test 
> org.apache.activemq.artemis.tests.integration.paging.MessagesExpiredPagingTest#testSendReceiveCORELarge



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901029=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901029
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 20:00
Start Date: 22/Jan/24 20:00
Worklog Time Spent: 10m 
  Work Description: jsmucr commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1904713369

   Thanks for the review @clebertsuconic, I'll process your suggestions as the 
first thing tomorrow morning.




Issue Time Tracking
---

Worklog Id: (was: 901029)
Time Spent: 1h  (was: 50m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4570) filter not applied to all brokers in cluster

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4570?focusedWorklogId=901028=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901028
 ]

ASF GitHub Bot logged work on ARTEMIS-4570:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:53
Start Date: 22/Jan/24 19:53
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4744:
URL: 
https://github.com/apache/activemq-artemis/pull/4744#issuecomment-1904702400

   Queues are not supposed to be changed... that's something recently added. I 
don't think your user (I know your user) is actually hitting an update queue.. 
Did you confirm that?




Issue Time Tracking
---

Worklog Id: (was: 901028)
Time Spent: 2h 10m  (was: 2h)

> filter not applied to all brokers in cluster
> 
>
> Key: ARTEMIS-4570
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4570
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Clustering
>Affects Versions: 2.31.2
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> When applying a new filter on a clustered queue, its remotebinding doesn't 
> get updated. The result is when sending a message that desn't match the 
> filter to the local queue the filter works, i.e. the local consumer won't get 
> the message. However if there is a remote consumer that message will be 
> delivered the the remote consumer (ON_DEMAND policy)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901025=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901025
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:51
Start Date: 22/Jan/24 19:51
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1904700025

   my only concern is storing a reference outside the data structure for the 
first message. treeMap.first() is there for right that purpose.
   
   
   on the implementation for first(), this is just returning:
   
   
  public E first() {
   return m.firstKey();
   }
   
   
   
   Which means you can always just return first().
   
   
   
   I'm not sure if you need to check for empty or not.. as you would need to 
double check on that.




Issue Time Tracking
---

Worklog Id: (was: 901025)
Time Spent: 50m  (was: 40m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901024=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901024
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:44
Start Date: 22/Jan/24 19:44
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462335068


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt5/spec/controlpackets/PublishTests.java:
##
@@ -311,15 +312,15 @@ public void testRetainFlagFalse() throws Exception {
 
   // send retained message
   producer.publish(TOPIC, RETAINED_PAYLOAD.getBytes(), 2, true);
-  Wait.assertTrue(() -> 
server.locateQueue(MQTTUtil.convertMqttTopicFilterToCore(MQTTUtil.MQTT_RETAIN_ADDRESS_PREFIX,
 TOPIC, MQTTUtil.MQTT_WILDCARD)).getMessageCount() == 1, 1000, 100);
+  Wait.assertTrue(() -> getRetainedMessageQueue(TOPIC).getMessageCount() 
== 1, 1000, 100);
 
   // send an unretained message; should *not* remove the existing retained 
message
   producer.publish(TOPIC, UNRETAINED_PAYLOAD.getBytes(), 2, false);
 
   producer.disconnect();
   producer.close();
 
-  Wait.assertFalse(() -> 
server.locateQueue(MQTTUtil.convertMqttTopicFilterToCore(MQTTUtil.MQTT_RETAIN_ADDRESS_PREFIX,
 TOPIC, MQTTUtil.MQTT_WILDCARD)).getMessageCount() > 1, 1000, 100);
+  Wait.assertFalse(() -> getRetainedMessageQueue(TOPIC).getMessageCount() 
> 1, 1000, 100);

Review Comment:
   If we just check for 2 and the count is somehow 3 or more then the check 
will pass even though the behavior is wrong.





Issue Time Tracking
---

Worklog Id: (was: 901024)
Time Spent: 50m  (was: 40m)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901023=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901023
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:43
Start Date: 22/Jan/24 19:43
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462333938


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
   }
}
 
+   protected void notifyScheduledReferencesUpdated() {
+  oldestMessage = null;
+   }
+
+   @Override
+   public MessageReference peekFirstScheduledMessage() {
+  synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+return null;
+ }
+ if (oldestMessage != null) {
+return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+MessageReference ref = scheduledReference.getRef();
+long refTimestamp = ref.getMessage().getTimestamp();
+if (refTimestamp < oldestTimestamp) {
+   oldestTimestamp = refTimestamp;
+   result = ref;
+}
+ }
+ oldestMessage = result;
+ return result;
+  }
+   }

Review Comment:
   when / if you apply my suggestion, please squash the commit as yours.





Issue Time Tracking
---

Worklog Id: (was: 901023)
Time Spent: 40m  (was: 0.5h)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901022=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901022
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:42
Start Date: 22/Jan/24 19:42
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462333062


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##
@@ -51,10 +51,13 @@ public class ScheduledDeliveryHandlerImpl implements 
ScheduledDeliveryHandler {
 
// This contains RefSchedules which are delegates to the real references
// just adding some information to keep it in order accordingly to the 
initial operations
+   // Do not forget to call notifyScheduledReferencesUpdated() when updating 
the set.

Review Comment:
   if you apply my suggestion please remove these calls..



##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##
@@ -51,10 +51,13 @@ public class ScheduledDeliveryHandlerImpl implements 
ScheduledDeliveryHandler {
 
// This contains RefSchedules which are delegates to the real references
// just adding some information to keep it in order accordingly to the 
initial operations
+   // Do not forget to call notifyScheduledReferencesUpdated() when updating 
the set.
private final TreeSet scheduledReferences = new TreeSet<>(new 
MessageReferenceComparator());
 
private final QueueMessageMetrics metrics;
 
+   private MessageReference oldestMessage = null;

Review Comment:
   remove this upon accepting my suggestion.. (and please squash the change as 
yours)





Issue Time Tracking
---

Worklog Id: (was: 901022)
Time Spent: 0.5h  (was: 20m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901021=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901021
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 19:42
Start Date: 22/Jan/24 19:42
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462332213


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
   }
}
 
+   protected void notifyScheduledReferencesUpdated() {
+  oldestMessage = null;
+   }
+
+   @Override
+   public MessageReference peekFirstScheduledMessage() {
+  synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+return null;
+ }
+ if (oldestMessage != null) {
+return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+MessageReference ref = scheduledReference.getRef();
+long refTimestamp = ref.getMessage().getTimestamp();
+if (refTimestamp < oldestTimestamp) {
+   oldestTimestamp = refTimestamp;
+   result = ref;
+}
+ }
+ oldestMessage = result;
+ return result;
+  }
+   }

Review Comment:
   ```suggestion
  @Override
  public MessageReference peekFirstScheduledMessage() {
 synchronized (scheduledReferences) {
if (scheduledReferences.isEmpty()) {
   return null;
}
   
RefScheduled refScheduled = scheduledReferences.first();
return refScheduled != null ? refScheduled.getRef() : null;
 }
  }
   ```
   
   Why not just use scheduledReferences.first()?
   
   
   I have been dealing with memory leaks in the past, especially the ones that 
I tested with the leak-tests I wrote, and this would actually eventually leak 
one message. Besides I think it's more efficient and less error prone to just 
call getfirst().
   
   
   in My suggestion I'm still checking for isEmpty(), which I'm not sure it's 
needed.. something to verify.





Issue Time Tracking
---

Worklog Id: (was: 901021)
Time Spent: 20m  (was: 10m)

> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901016=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901016
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 18:55
Start Date: 22/Jan/24 18:55
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462275922


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/mqtt5/spec/controlpackets/PublishTests.java:
##
@@ -653,6 +654,10 @@ public void messageArrived(String topic, MqttMessage 
message) throws Exception {
   consumer.close();
}
 
+   private Queue getRetainedMessageQueue(String TOPIC) {
+  return 
server.locateQueue(MQTTUtil.convertMqttTopicFilterToCore(MQTTUtil.MQTT_RETAIN_ADDRESS_PREFIX,
 TOPIC, server.getConfiguration().getWildcardConfiguration()));
+   }

Review Comment:
   Can you give me an example of what you mean?





Issue Time Tracking
---

Worklog Id: (was: 901016)
Time Spent: 40m  (was: 0.5h)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> syntax|https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax]
>  the conversion to/from this syntax breaks.
> For example, when using the default wildcard syntax if an MQTT topic filter 
> contains a {{.}} the conversion from the MQTT wildcard syntax to the core 
> wildcard syntax and back will result in the {{.}} being replaced with a {{/}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?focusedWorklogId=901014=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901014
 ]

ASF GitHub Bot logged work on ARTEMIS-4575:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 18:43
Start Date: 22/Jan/24 18:43
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on PR #4754:
URL: 
https://github.com/apache/activemq-artemis/pull/4754#issuecomment-1904594225

   I'm actually planning to cut a release this week. I will send a heads up to 
the dev-list... 




Issue Time Tracking
---

Worklog Id: (was: 901014)
Time Spent: 1h 40m  (was: 1.5h)

> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.32.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4532) MQTT-to-core wildcard conversion is broken

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4532?focusedWorklogId=901007=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901007
 ]

ASF GitHub Bot logged work on ARTEMIS-4532:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 17:30
Start Date: 22/Jan/24 17:30
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4710:
URL: https://github.com/apache/activemq-artemis/pull/4710#discussion_r1462187419


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/config/WildcardConfiguration.java:
##
@@ -119,19 +138,94 @@ public String getSingleWordString() {
   return singleWordString;
}
 
-   public void setSingleWord(char singleWord) {
+   public WildcardConfiguration setSingleWord(char singleWord) {
   this.singleWord = singleWord;
   this.singleWordString = String.valueOf(singleWord);
+  return this;
}
 
-   public String convert(String filter, WildcardConfiguration to) {
-  if (this.equals(to)) {
- return filter;
+   /**
+* Convert the input from this WildcardConfiguration into the specified 
WildcardConfiguration.
+*
+* If the input already contains characters defined in the target 
WildcardConfiguration then those characters will
+* be escaped and preserved as such in the returned String. That said, 
wildcard characters which are the same
+* between the two configurations will not be escaped
+*
+* If the input already contains escaped characters defined in this 
WildcardConfiguration then those characters will
+* be unescaped after conversion and restored in the returned String.
+*
+* @param input  the String to convert
+* @param target the WildcardConfiguration to convert the input into
+* @return the converted String
+*/
+   public String convert(final String input, final WildcardConfiguration 
target) {
+  if (this.equals(target)) {
+ return input;
   } else {
- return filter
-.replace(getDelimiter(), to.getDelimiter())
-.replace(getSingleWord(), to.getSingleWord())
-.replace(getAnyWords(), to.getAnyWords());
+ boolean escaped = isEscaped(input);
+ StringBuilder result;
+ if (!escaped) {
+result = new StringBuilder(target.escape(input, this));
+ } else {
+result = new StringBuilder(input);
+ }
+ replaceChar(result, getDelimiter(), target.getDelimiter());
+ replaceChar(result, getSingleWord(), target.getSingleWord());
+ replaceChar(result, getAnyWords(), target.getAnyWords());
+ if (escaped) {
+return unescape(result.toString());
+ } else {
+return result.toString();
+ }
+  }
+   }
+
+   private String escape(final String input, WildcardConfiguration from) {
+  String result = input.replace(escapeString, escapeString + escapeString);
+  if (delimiter != from.getDelimiter()) {
+ result = result.replace(getDelimiterString(), escapeString + 
getDelimiterString());
+  }
+  if (singleWord != from.getSingleWord()) {
+ result = result.replace(getSingleWordString(), escapeString + 
getSingleWordString());
+  }
+  if (anyWords != from.getAnyWords()) {
+ result = result.replace(getAnyWordsString(), escapeString + 
getAnyWordsString());
+  }
+  return result;
+   }
+
+   private String unescape(final String input) {
+  return input
+ .replace(escapeString + escapeString, escapeString)
+ .replace(ESCAPE + getDelimiterString(), getDelimiterString())
+ .replace(ESCAPE + getSingleWordString(), getSingleWordString())
+ .replace(ESCAPE + getAnyWordsString(), getAnyWordsString());
+   }
+
+   private boolean isEscaped(final String input) {
+  for (int i = 0; i < input.length() - 1; i++) {
+ if (input.charAt(i) == ESCAPE && (input.charAt(i + 1) == 
getDelimiter() || input.charAt(i + 1) == getSingleWord() || input.charAt(i + 1) 
== getAnyWords())) {
+return true;
+ }
+  }

Review Comment:
   Shouldn't the `input.length() - 1` mitigate this?





Issue Time Tracking
---

Worklog Id: (was: 901007)
Time Spent: 0.5h  (was: 20m)

> MQTT-to-core wildcard conversion is broken
> --
>
> Key: ARTEMIS-4532
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4532
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently when an MQTT topic filter contains characters from the configured 
> [wildcard 
> 

[jira] [Work logged] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?focusedWorklogId=900997=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900997
 ]

ASF GitHub Bot logged work on ARTEMIS-4575:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 16:08
Start Date: 22/Jan/24 16:08
Worklog Time Spent: 10m 
  Work Description: joshb1050 commented on PR #4754:
URL: 
https://github.com/apache/activemq-artemis/pull/4754#issuecomment-1904327366

   @tabish121 Thanks for the quick PR and merge on this—is there an estimate 
for when a new release will be cut with this change? 




Issue Time Tracking
---

Worklog Id: (was: 900997)
Time Spent: 1.5h  (was: 1h 20m)

> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.32.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[Timothy A. Bish (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy A. Bish resolved ARTEMIS-4575.
--
Fix Version/s: 2.32.0
 Assignee: Timothy A. Bish
   Resolution: Fixed

> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.32.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[Timothy A. Bish (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy A. Bish updated ARTEMIS-4575:
-
Affects Version/s: 2.31.2

> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.31.2
>Reporter: Josh Byster
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (ARTEMIS-4580) Security settings for FQQN not enforced on send

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-4580.
-
Fix Version/s: 2.32.0
   Resolution: Fixed

> Security settings for FQQN not enforced on send
> ---
>
> Key: ARTEMIS-4580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4580
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (ARTEMIS-4436) Artemis is logging warnings during clean shutdown of server in cluster

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-4436.
-
Fix Version/s: 2.32.0
   Resolution: Fixed

> Artemis is logging warnings during clean shutdown of server in cluster
> --
>
> Key: ARTEMIS-4436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4436
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Clustering
>Affects Versions: 2.30.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
> Fix For: 2.32.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> If a node from a cluster shutdowns cleanly this shouldn't create WARN 
> messages in the logs 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809502#comment-17809502
 ] 

ASF subversion and git services commented on ARTEMIS-4575:
--

Commit 54f5dae458ab7bc1ce554e8c5b74c8fa30401833 in activemq-artemis's branch 
refs/heads/main from Timothy Bish
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=54f5dae458 ]

ARTEMIS-4575 Only start the consumers that were added

Change from forcing a session start cycle on each consumer add
event and start only those consumers that were added which will
trigger a prompt delivery action on each. The session should be
marked started on create to account for the remove of the start
on each consumer add event.


> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Josh Byster
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4575) Don't start all previous consumers when new consumer added

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4575?focusedWorklogId=900968=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900968
 ]

ASF GitHub Bot logged work on ARTEMIS-4575:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 15:15
Start Date: 22/Jan/24 15:15
Worklog Time Spent: 10m 
  Work Description: jbertram merged PR #4754:
URL: https://github.com/apache/activemq-artemis/pull/4754




Issue Time Tracking
---

Worklog Id: (was: 900968)
Time Spent: 1h 20m  (was: 1h 10m)

> Don't start all previous consumers when new consumer added
> --
>
> Key: ARTEMIS-4575
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4575
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Josh Byster
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I was running a benchmark to add many consumers, and I see that the marginal 
> cost of adding a new consumer increases due to a linear-time iteration 
> through all the existing consumers with OpenWire. It becomes very slow to add 
> a new consumer when there are already 100k+ on a session, for example. We 
> have thousands of topics and we see a huge performance slowdown due to this.
> More specifically, the stack trace:
> {code:java}
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:73)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369)
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:352)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddConsumer(OpenWireConnection.java:1280)
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addConsumer(OpenWireConnection.java:1001)
> org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.start(AMQSession.java:257)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.start(ServerSessionImpl.java:1699)
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.setStarted(ServerSessionImpl.java:2166)
>    {code}
> {{Most of the time is spent in this method, starting consumers that have 
> previously been started:}}
> {code:java}
> private void setStarted(final boolean s) {
>Set consumersClone = new HashSet<>(consumers.values());
>for (ServerConsumer consumer : consumersClone) {
>   consumer.setStarted(s);
>}
>started = s;
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (ARTEMIS-4580) Security settings for FQQN not enforced on send

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809501#comment-17809501
 ] 

ASF subversion and git services commented on ARTEMIS-4580:
--

Commit a70c421493384a5e8c4501b9b8f948c2e875918e in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a70c421493 ]

ARTEMIS-4580 security settings for FQQN not enforced on send


> Security settings for FQQN not enforced on send
> ---
>
> Key: ARTEMIS-4580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4580
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4580) Security settings for FQQN not enforced on send

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4580?focusedWorklogId=900967=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900967
 ]

ASF GitHub Bot logged work on ARTEMIS-4580:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 15:12
Start Date: 22/Jan/24 15:12
Worklog Time Spent: 10m 
  Work Description: jbertram merged PR #4755:
URL: https://github.com/apache/activemq-artemis/pull/4755




Issue Time Tracking
---

Worklog Id: (was: 900967)
Time Spent: 50m  (was: 40m)

> Security settings for FQQN not enforced on send
> ---
>
> Key: ARTEMIS-4580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4580
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (ARTEMIS-4436) Artemis is logging warnings during clean shutdown of server in cluster

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809499#comment-17809499
 ] 

ASF subversion and git services commented on ARTEMIS-4436:
--

Commit 2269ad417e1f177e0a8e64e630c0f27c7bdcd1e0 in activemq-artemis's branch 
refs/heads/main from Emmanuel Hugonnet
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2269ad417e ]

ARTEMIS-4436 Artemis is logging warnings during clean shutdown of server
in cluster.

When we know that a node leaves a clustercleanly we shouldn't log WARN
messages about it.

Signed-off-by: Emmanuel Hugonnet 


> Artemis is logging warnings during clean shutdown of server in cluster
> --
>
> Key: ARTEMIS-4436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4436
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Clustering
>Affects Versions: 2.30.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> If a node from a cluster shutdowns cleanly this shouldn't create WARN 
> messages in the logs 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4436) Artemis is logging warnings during clean shutdown of server in cluster

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4436?focusedWorklogId=900966=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900966
 ]

ASF GitHub Bot logged work on ARTEMIS-4436:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 15:11
Start Date: 22/Jan/24 15:11
Worklog Time Spent: 10m 
  Work Description: clebertsuconic merged PR #4628:
URL: https://github.com/apache/activemq-artemis/pull/4628




Issue Time Tracking
---

Worklog Id: (was: 900966)
Time Spent: 3h  (was: 2h 50m)

> Artemis is logging warnings during clean shutdown of server in cluster
> --
>
> Key: ARTEMIS-4436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4436
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Clustering
>Affects Versions: 2.30.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> If a node from a cluster shutdowns cleanly this shouldn't create WARN 
> messages in the logs 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Work logged] (ARTEMIS-4580) Security settings for FQQN not enforced on send

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-4580?focusedWorklogId=900965=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900965
 ]

ASF GitHub Bot logged work on ARTEMIS-4580:
---

Author: ASF GitHub Bot
Created on: 22/Jan/24 15:11
Start Date: 22/Jan/24 15:11
Worklog Time Spent: 10m 
  Work Description: tabish121 commented on PR #4755:
URL: 
https://github.com/apache/activemq-artemis/pull/4755#issuecomment-1904208947

   LGTM, looks to need a rebase before merging




Issue Time Tracking
---

Worklog Id: (was: 900965)
Time Spent: 40m  (was: 0.5h)

> Security settings for FQQN not enforced on send
> ---
>
> Key: ARTEMIS-4580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4580
> 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] [Assigned] (OPENWIRE-6) Fix build on JDK 8

[Christopher L. Shannon (Jira)]

 [ 
https://issues.apache.org/jira/browse/OPENWIRE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher L. Shannon reassigned OPENWIRE-6:
-

Assignee: Christopher L. Shannon

> Fix build on JDK  8
> ---
>
> Key: OPENWIRE-6
> URL: https://issues.apache.org/jira/browse/OPENWIRE-6
> Project: ActiveMQ OpenWire
>  Issue Type: Bug
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 1.0.0
>
>
> Currently there are some incompactible dependencies with scalate and scala 
> causing the build to fail on JDK 8 update 60.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)