[jira] [Resolved] (ARTEMIS-2167) Queues created by MQTT retained messages are not auto deleted
[ https://issues.apache.org/jira/browse/ARTEMIS-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2167. - Assignee: Justin Bertram Resolution: Duplicate > Queues created by MQTT retained messages are not auto deleted > - > > Key: ARTEMIS-2167 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2167 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.6.2 >Reporter: Wim Pool >Assignee: Justin Bertram >Priority: Major > > We are sending MQTT retained messages to a MQTT topic and when the topic is > not active anymore is cleared by sending an empty message. When the topic is > cleared we expect the address and queue that are auto-created in Artemis are > deleted as both auto-delete-jms-queues and auto-delete-jms-topics are true > and the message-count = 0 and subscriptions = 0. > We also tested using not retained messages then the auto-deletion works as > expected. > We expect is has something to do with Artemis creating durable queues for > retained messages but we can't find anything in the documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2168) Fix "populate-validated-user" feature for AMQP produced messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2168. - Resolution: Won't Do Given the discussions on the corresponding PRs and the lack of movement on this issue I'm closing this as "Won't Do". Feel free to re-open if this issue needs to be revisited. > Fix "populate-validated-user" feature for AMQP produced messages > > > Key: ARTEMIS-2168 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2168 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Priority: Major > > Fix feature: https://issues.apache.org/jira/browse/ARTEMIS-584 for AMQP > produced messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2341) Instructions for multicast setup 'route add' on MacOS
[
https://issues.apache.org/jira/browse/ARTEMIS-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836849#comment-17836849
]
Justin Bertram commented on ARTEMIS-2341:
-
[~clebertsuconic], can you verify this?
> Instructions for multicast setup 'route add' on MacOS
> -
>
> Key: ARTEMIS-2341
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2341
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Environment: MacOS
>Reporter: Federico Valeri
>Priority: Major
>
> UDP discovery on localhost (all the nodes are in one machine): the MacOS
> command to enable the multicast route to the loopback interface doesn't work
> [1].
>
> We should change the command to:
> {code}
> sudo route -nv add -net 231.7.7.8 -interface lo0
> {code}
> Replace 231.7.7.8 with the desired address in the multicast range.
> To disable the rule, just drop it from the routing table:
> {code}
> sudo route -v delete -inet 231.7.7.8
> {code}
>
> Remember to also set the localBindAddress to 127.0.0.1 on clients:
> {code:java}
> UDPBroadcastEndpointFactory udpConfig = new UDPBroadcastEndpointFactory();
> udpConfig.setGroupAddress("231.7.7.8").setGroupPort(9876).setLocalBindAddress("127.0.0.1");
> DiscoveryGroupConfiguration dgConfig = new DiscoveryGroupConfiguration();
> dgConfig.setBroadcastEndpointFactory(udpConfig);
> ConnectionFactory cf =
> ActiveMQJMSClient.createConnectionFactoryWithHA(dgConfig, JMSFactoryType.CF);
> {code}
> Or using JNDI:
> {code}
> connectionFactory.ConnectionFactory =
> udp://231.7.7.8:9876?localBindAddress=127.0.0.1
> {code}
>
> [1]
> [https://activemq.apache.org/components/artemis/documentation/latest/perf-tuning.html#udp-not-working]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-2039) tearDown may interrupt wrong threads after failures
[ https://issues.apache.org/jira/browse/ARTEMIS-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2039. - Resolution: Duplicate > tearDown may interrupt wrong threads after failures > --- > > Key: ARTEMIS-2039 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2039 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.5.5 >Reporter: Brad Maxwell >Priority: Major > > If a failover is happening, and consumers are stuck for any reason during the > process, HornetQ might issue interrupts on wrong threads. > This is because the list of threads is captured before a time wait what could > cause issues with the system is the thread doen't belong to the consumer any > longer. > How reproducible: > On a MDB that's receiving messages and sending messages to a remote node, > pull the cable (or disable network). and make failover happen to a backup. > Steps to Reproduce: > 1. Deploy the MDB on that condition > 2. Pull the network cable > 3. failover that server. > Actual results: > JCA will have connections into invalid state. You will get exception on an > infinite loop. > There's a secondary issue here as those connections shouldn't come back to > the pool. > Expected results: > Connections to reconnect successfully without -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2035) org.apache.activemq.artemis.uri.JGroupsSchema can only serialize Artemis JGroups endpoint factories
[ https://issues.apache.org/jira/browse/ARTEMIS-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836842#comment-17836842 ] Justin Bertram commented on ARTEMIS-2035: - [~ehsavoie], do you still need this? > org.apache.activemq.artemis.uri.JGroupsSchema can only serialize Artemis > JGroups endpoint factories > --- > > Key: ARTEMIS-2035 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2035 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.5.6 >Reporter: Emmanuel Hugonnet >Priority: Major > > If an application server provides its own BroadcastEndpointFactory then it > will never be converted to an URI even if it could provide the channelName or > auth parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=914497=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914497
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 13/Apr/24 13:27
Start Date: 13/Apr/24 13:27
Worklog Time Spent: 10m
Work Description: AndyDeMauriceGEDigital commented on PR #34:
URL:
https://github.com/apache/activemq-nms-openwire/pull/34#issuecomment-2053646553
Replace with https://github.com/apache/activemq-nms-openwire/pull/37
Issue Time Tracking
---
Worklog Id: (was: 914497)
Time Spent: 40m (was: 0.5h)
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=914496=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914496
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 13/Apr/24 13:26
Start Date: 13/Apr/24 13:26
Worklog Time Spent: 10m
Work Description: AndyDeMauriceGEDigital opened a new pull request, #37:
URL: https://github.com/apache/activemq-nms-openwire/pull/37
Fix for the thread sync issues as reported in AMQNET-727.
Note that the first part of the fix (in DeliverAcks), comes from this fix in
the Java client:
https://github.com/apache/activemq/commit/c02bc648460059b6dbc201fa21b7ee0ce2445082
The 2nd part of the fix (in AfterMessageIsConsumedAsync), is just a slight
change to make the call to AckLaterAsync occur while the lock is held.
Issue Time Tracking
---
Worklog Id: (was: 914496)
Time Spent: 0.5h (was: 20m)
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQNET-727) Thread sync error with MessageConsumer.pendingAck
[
https://issues.apache.org/jira/browse/AMQNET-727?focusedWorklogId=914495=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-914495
]
ASF GitHub Bot logged work on AMQNET-727:
-
Author: ASF GitHub Bot
Created on: 13/Apr/24 13:19
Start Date: 13/Apr/24 13:19
Worklog Time Spent: 10m
Work Description: AndyDeMauriceGEDigital closed pull request #34: Fix for
AMQNET-727
URL: https://github.com/apache/activemq-nms-openwire/pull/34
Issue Time Tracking
---
Worklog Id: (was: 914495)
Time Spent: 20m (was: 10m)
> Thread sync error with MessageConsumer.pendingAck
> -
>
> Key: AMQNET-727
> URL: https://issues.apache.org/jira/browse/AMQNET-727
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 1.8.0
>Reporter: Andy DeMaurice
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> pendingAck is accessed by multiple threads; in most places where it is
> written, it is done along with accessing *deliveredMessages*, so it is
> written within a *lock(this.deliveredMessages)* block.
> However, this call stack shows where pendingAck gets assigned to a new
> MessageAck object, NOT within the lock... and it is subject to being
> overwritten by another thread (usually the other thread is in
> MessageConsumer.Acknowledge() :
>
> Apache.NMS.ActiveMQ.MessageConsumer.AckLater(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Apache.NMS.ActiveMQ.AckType)
> Apache.NMS.ActiveMQ.MessageConsumer.AfterMessageIsConsumed(Apache.NMS.ActiveMQ.Commands.MessageDispatch,
> Boolean)
> Apache.NMS.ActiveMQ.MessageConsumer.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Dispatch(Apache.NMS.ActiveMQ.Commands.MessageDispatch)
> Apache.NMS.ActiveMQ.SessionExecutor.Iterate()
> Apache.NMS.ActiveMQ.Threads.DedicatedTaskRunner.Run()
>
> The usual symptom I see is a NullReferenceException in this section of code
> within AckLater; because pendingAck has been set to null by another thread:
>
> if(oldPendingAck == null)
> {
> pendingAck.FirstMessageId = pendingAck.LastMessageId;
> }
> else if(oldPendingAck.AckType == pendingAck.AckType)
> {
> pendingAck.FirstMessageId = oldPendingAck.FirstMessageId;
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
