[jira] [Commented] (ARTEMIS-4784) Large messages are being kept on the ReplicationEndpoint after they are closed.
[ https://issues.apache.org/jira/browse/ARTEMIS-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854241#comment-17854241 ] ASF subversion and git services commented on ARTEMIS-4784: -- Commit 4eb90765a7f2a6ca49664097cad7651cbc3e5439 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4eb90765a7 ] ARTEMIS-4813 Large Message in replication / sync could lose part of the body This is a regressio after ARTEMIS-4784 > Large messages are being kept on the ReplicationEndpoint after they are > closed. > --- > > Key: ARTEMIS-4784 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4784 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The entries for these large messages need to be removed as soon as the file > is closed: > https://github.com/apache/activemq-artemis/blob/49189cd7e63a64fcda947dbd72fd7849348b71c9/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationEndpoint.java#L134 > When a remove is needed a new object should be created instead of keeping the > hash longer. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
[ https://issues.apache.org/jira/browse/ARTEMIS-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854240#comment-17854240 ] ASF subversion and git services commented on ARTEMIS-4813: -- Commit 4eb90765a7f2a6ca49664097cad7651cbc3e5439 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4eb90765a7 ] ARTEMIS-4813 Large Message in replication / sync could lose part of the body This is a regressio after ARTEMIS-4784 > LargeMessages could lose a body while in sync if backup becomes activated > - > > Key: ARTEMIS-4813 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a regression because of ARTEMIS-4784 > If a large message is received while synchronization still happening, and if > the backup becomes online right away you may lose partial of the large > message. > testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
[ https://issues.apache.org/jira/browse/ARTEMIS-4813?focusedWorklogId=923081=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923081 ] ASF GitHub Bot logged work on ARTEMIS-4813: --- Author: ASF GitHub Bot Created on: 12/Jun/24 04:31 Start Date: 12/Jun/24 04:31 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4971: URL: https://github.com/apache/activemq-artemis/pull/4971 Issue Time Tracking --- Worklog Id: (was: 923081) Time Spent: 20m (was: 10m) > LargeMessages could lose a body while in sync if backup becomes activated > - > > Key: ARTEMIS-4813 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a regression because of ARTEMIS-4784 > If a large message is received while synchronization still happening, and if > the backup becomes online right away you may lose partial of the large > message. > testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4780) Artemis web console does not ever set 'artemisJmxDomain' in localStorage
[
https://issues.apache.org/jira/browse/ARTEMIS-4780?focusedWorklogId=923066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923066
]
ASF GitHub Bot logged work on ARTEMIS-4780:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 03:18
Start Date: 12/Jun/24 03:18
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #18:
URL:
https://github.com/apache/activemq-artemis-console/pull/18#issuecomment-2162027006
@andytaylor Up to you—whichever makes most sense. Thanks for tackling!
Issue Time Tracking
---
Worklog Id: (was: 923066)
Time Spent: 1h 20m (was: 1h 10m)
> Artemis web console does not ever set 'artemisJmxDomain' in localStorage
>
>
> Key: ARTEMIS-4780
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4780
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.32.0
>Reporter: Josh Byster
>Assignee: Andy Taylor
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We relocate our artemis packages as part of our shading process.
> I did set up:
>
> {code:java}
> aActiveMQServer.getConfiguration().setJMXDomain("com.abc.shaded.org.apache.activemq.artemis");
> {code}
> However the web console does not show up. I noticed in the code it's because
> we try to read in localStorage['artemisJmxDomain'] but never actually set it
> as far as I can tell. Thus we always default to org.apache.activemq.artemis.
> Everything works properly when setting localStorage['artemisJmxDomain'] =
> "com.abc.shaded.org.apache.activemq.artemis"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923065
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 12/Jun/24 03:14
Start Date: 12/Jun/24 03:14
Worklog Time Spent: 10m
Work Description: joshb1050 opened a new pull request, #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972
Currently, with 500K+ queues, the cleanup step of TempQueueCleanerUpper
requires invoking WildcardAddressManager#getDirectBindings, which is O(k) in
the number of queues.
From method profiling, this can consume up to 95% of our CPU time when
needing to clean up many of these.
Add a new map to keep track of the direct bindings, and add a test assertion
that fails if we don't properly remove it.
Issue Time Tracking
---
Worklog Id: (was: 923065)
Remaining Estimate: 0h
Time Spent: 10m
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Byster updated ARTEMIS-4814:
-
Issue Type: Task (was: New Feature)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4814) Remove linear iteration to get direct bindings
Josh Byster created ARTEMIS-4814:
Summary: Remove linear iteration to get direct bindings
Key: ARTEMIS-4814
URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
Project: ActiveMQ Artemis
Issue Type: New Feature
Components: Broker
Reporter: Josh Byster
Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
in the number of queues.
>From method profiling, this can consume up to 95% of our CPU time when needing
>to clean up many of these.
It would be nice to make this more efficient, which shouldn't be difficult
given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923046=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923046
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 22:54
Start Date: 11/Jun/24 22:54
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161730473
@jbertram thank you—it's strange since I did run `mvn checkstyle:check` and
`mvn -Pdev install` and both passed with the checkstyle error. It's also
unclear given that `check` passed for 2 of the 3 failures. I have corrected the
latest one that I see on CI though.
Issue Time Tracking
---
Worklog Id: (was: 923046)
Time Spent: 1h 50m (was: 1h 40m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
[ https://issues.apache.org/jira/browse/ARTEMIS-4813?focusedWorklogId=923044=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923044 ] ASF GitHub Bot logged work on ARTEMIS-4813: --- Author: ASF GitHub Bot Created on: 11/Jun/24 22:20 Start Date: 11/Jun/24 22:20 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4971: URL: https://github.com/apache/activemq-artemis/pull/4971 This is a regressio after ARTEMIS-4784 Issue Time Tracking --- Worklog Id: (was: 923044) Remaining Estimate: 0h Time Spent: 10m > LargeMessages could lose a body while in sync if backup becomes activated > - > > Key: ARTEMIS-4813 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This is a regression because of ARTEMIS-4784 > If a large message is received while synchronization still happening, and if > the backup becomes online right away you may lose partial of the large > message. > testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4813) LargeMessages could lose a body while in sync if backup becomes activated
Clebert Suconic created ARTEMIS-4813: Summary: LargeMessages could lose a body while in sync if backup becomes activated Key: ARTEMIS-4813 URL: https://issues.apache.org/jira/browse/ARTEMIS-4813 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.34.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.35.0 This is a regression because of ARTEMIS-4784 If a large message is received while synchronization still happening, and if the backup becomes online right away you may lose partial of the large message. testBackupStartsWhenPrimaryIsREceivingLargeMessage is failing because of this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923041=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923041
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 22:00
Start Date: 11/Jun/24 22:00
Worklog Time Spent: 10m
Work Description: jbertram commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161671151
For what it's worth you can run checkstyle locally using:
```
mvn -Pdev install
```
See the [hacking
guide](https://activemq.apache.org/components/artemis/documentation/hacking-guide/#using-the-dev-profile)
for more details.
Issue Time Tracking
---
Worklog Id: (was: 923041)
Time Spent: 1h 40m (was: 1.5h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923039=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923039
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:47
Start Date: 11/Jun/24 21:47
Worklog Time Spent: 10m
Work Description: joshb1050 commented on PR #4966:
URL:
https://github.com/apache/activemq-artemis/pull/4966#issuecomment-2161654314
Checkstyle is fixed now as well.
Issue Time Tracking
---
Worklog Id: (was: 923039)
Time Spent: 1.5h (was: 1h 20m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923037=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923037
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:45
Start Date: 11/Jun/24 21:45
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635514051
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
This is done.
Issue Time Tracking
---
Worklog Id: (was: 923037)
Time Spent: 1h 10m (was: 1h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923038=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923038
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:45
Start Date: 11/Jun/24 21:45
Worklog Time Spent: 10m
Work Description: joshb1050 commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635514337
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/AddressSettings.java:
##
@@ -1604,6 +1619,10 @@ public void decode(ActiveMQBuffer buffer, boolean
tryCompatible) {
prefetchPageMessages = BufferHelper.readNullableInteger(buffer);
}
+ if (buffer.readableBytes() > 0) {
+ intermediateMessageBufferInitialSize =
BufferHelper.readNullableInteger(buffer);
+ }
+
Review Comment:
Missed that—done now.
Issue Time Tracking
---
Worklog Id: (was: 923038)
Time Spent: 1h 20m (was: 1h 10m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923034=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923034
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:22
Start Date: 11/Jun/24 21:22
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635493471
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
Specify the default value here as with the other elements (i.e. `8192`).
Issue Time Tracking
---
Worklog Id: (was: 923034)
Time Spent: 1h (was: 50m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923033=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923033
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:20
Start Date: 11/Jun/24 21:20
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635493471
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -4457,6 +4457,15 @@
+
Review Comment:
Specify the default value here as with the other elements.
Issue Time Tracking
---
Worklog Id: (was: 923033)
Time Spent: 50m (was: 40m)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?focusedWorklogId=923032=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923032
]
ASF GitHub Bot logged work on ARTEMIS-4809:
---
Author: ASF GitHub Bot
Created on: 11/Jun/24 21:19
Start Date: 11/Jun/24 21:19
Worklog Time Spent: 10m
Work Description: jbertram commented on code in PR #4966:
URL: https://github.com/apache/activemq-artemis/pull/4966#discussion_r1635492310
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/AddressSettings.java:
##
@@ -1604,6 +1619,10 @@ public void decode(ActiveMQBuffer buffer, boolean
tryCompatible) {
prefetchPageMessages = BufferHelper.readNullableInteger(buffer);
}
+ if (buffer.readableBytes() > 0) {
+ intermediateMessageBufferInitialSize =
BufferHelper.readNullableInteger(buffer);
+ }
+
Review Comment:
Notice the comment below. This code should be removed.
Issue Time Tracking
---
Worklog Id: (was: 923032)
Time Spent: 40m (was: 0.5h)
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.111.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923031=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923031 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 21:12 Start Date: 11/Jun/24 21:12 Worklog Time Spent: 10m Work Description: jbertram merged PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969 Issue Time Tracking --- Worklog Id: (was: 923031) Time Spent: 40m (was: 0.5h) > Upgrade Netty to 4.1.111.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4811) Upgrade Netty to 4.1.111.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854199#comment-17854199 ] ASF subversion and git services commented on ARTEMIS-4811: -- Commit 2aff6504e17f2db95644d3dcc7058eed97cd1390 in activemq-artemis's branch refs/heads/main from Emmanuel Hugonnet [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=2aff6504e1 ] ARTEMIS-4811 upgrade Netty to 4.1.111.Final Signed-off-by: Emmanuel Hugonnet > Upgrade Netty to 4.1.111.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4811) Upgrade Netty to 4.1.111.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated ARTEMIS-4811: --- Summary: Upgrade Netty to 4.1.111.Final (was: Upgrade Netty to 4.1.110.Final) > Upgrade Netty to 4.1.111.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.110.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923022=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923022 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 19:27 Start Date: 11/Jun/24 19:27 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969#issuecomment-2161463400 Actually 4.1.111.Final has already been released so just update your PR and this problem should go away. Issue Time Tracking --- Worklog Id: (was: 923022) Time Spent: 0.5h (was: 20m) > Upgrade Netty to 4.1.110.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4811) Upgrade Netty to 4.1.110.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4811?focusedWorklogId=923021=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923021 ] ASF GitHub Bot logged work on ARTEMIS-4811: --- Author: ASF GitHub Bot Created on: 11/Jun/24 19:22 Start Date: 11/Jun/24 19:22 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4969: URL: https://github.com/apache/activemq-artemis/pull/4969#issuecomment-2161456131 Looks like we may need to wait for 4.1.111.Final in order to get https://github.com/netty/netty/issues/14080. Issue Time Tracking --- Worklog Id: (was: 923021) Time Spent: 20m (was: 10m) > Upgrade Netty to 4.1.110.Final > -- > > Key: ARTEMIS-4811 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4811 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4812?focusedWorklogId=922981=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922981 ] ASF GitHub Bot logged work on ARTEMIS-4812: --- Author: ASF GitHub Bot Created on: 11/Jun/24 16:03 Start Date: 11/Jun/24 16:03 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4970: URL: https://github.com/apache/activemq-artemis/pull/4970 Issue Time Tracking --- Worklog Id: (was: 922981) Time Spent: 20m (was: 10m) > PageCursorInfo should be cleared on its Maps when page is marked as complete > > > Key: ARTEMIS-4812 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Say you have a paged destination where there is a lazy consumer. The other > queues will keep consuming, and they will mark a page as complete. However > PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared > upon completion otherwise they will only be GCed when the page file is > removed and the entries for PageCursorInfo removed. > IntObjectHashMap also keeps an array of integers in memory and it won't > remove it when all elements are removed. to the reference to IntObjectHashMap > has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854108#comment-17854108 ] ASF subversion and git services commented on ARTEMIS-4812: -- Commit 178f2e4b4d8b9ab0ba16750a716179f41e2ec8c5 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=178f2e4b4d ] ARTEMIS-4812 Avoid IntObject accumulation after Page is set as complete this could lead to OME if a lazy consumer is there for a long time with all pages being removed. > PageCursorInfo should be cleared on its Maps when page is marked as complete > > > Key: ARTEMIS-4812 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Say you have a paged destination where there is a lazy consumer. The other > queues will keep consuming, and they will mark a page as complete. However > PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared > upon completion otherwise they will only be GCed when the page file is > removed and the entries for PageCursorInfo removed. > IntObjectHashMap also keeps an array of integers in memory and it won't > remove it when all elements are removed. to the reference to IntObjectHashMap > has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9506. --- Resolution: Fixed > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?focusedWorklogId=922974=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922974 ] ASF GitHub Bot logged work on AMQ-9506: --- Author: ASF GitHub Bot Created on: 11/Jun/24 15:27 Start Date: 11/Jun/24 15:27 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1231: URL: https://github.com/apache/activemq/pull/1231 Issue Time Tracking --- Worklog Id: (was: 922974) Time Spent: 20m (was: 10m) > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854098#comment-17854098 ] ASF subversion and git services commented on AMQ-9506: -- Commit 9d11e0d7e96c4871e190d0c99aa0f3cdc8ffb8db in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=9d11e0d7e ] Merge pull request #1231 from jbonofre/AMQ-9506 AMQ-9506: Upgrade to Jackson 2.17.1 > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854097#comment-17854097 ] ASF subversion and git services commented on AMQ-9506: -- Commit ba0f7b6690de62279103d68d29f08799d10fa3b0 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ba0f7b669 ] AMQ-9506: Upgrade to Jackson 2.17.1 > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> produced to target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> produced to target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> produced to target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> produced to target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4812?focusedWorklogId=922971=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922971 ] ASF GitHub Bot logged work on ARTEMIS-4812: --- Author: ASF GitHub Bot Created on: 11/Jun/24 14:23 Start Date: 11/Jun/24 14:23 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4970: URL: https://github.com/apache/activemq-artemis/pull/4970 this could lead to OME if a lazy consumer is there for a long time with all pages being removed. Issue Time Tracking --- Worklog Id: (was: 922971) Remaining Estimate: 0h Time Spent: 10m > PageCursorInfo should be cleared on its Maps when page is marked as complete > > > Key: ARTEMIS-4812 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.34.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.35.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Say you have a paged destination where there is a lazy consumer. The other > queues will keep consuming, and they will mark a page as complete. However > PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared > upon completion otherwise they will only be GCed when the page file is > removed and the entries for PageCursorInfo removed. > IntObjectHashMap also keeps an array of integers in memory and it won't > remove it when all elements are removed. to the reference to IntObjectHashMap > has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Description:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being produced to the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being produced to the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being produced to the target
node, it can lead to message not able to be delivered to new consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
produced to the target node, If large messages are being delivered, the thread
In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is paused
then the Runnable of deliverLargeMessage is being run, leading to a situation
were the message won't be delivered to new consumers
{*}Notes{*}:
* PauseRunnable does not await for task in {{executor}} to complete,
deliverLargeMessage do create task in executor
*
** We can see that even after PauseRunnable has complete,
deliverLargeMessage's task is running after.
* If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
{{blockedOnFlowControl}} to true, before calling pause, it prevent putting new
task on executor and mitigate the issue, but It feels weird and I think there
might still be race condition
was:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being produced to the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being produced to the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being produced to the target
node, it can lead to message not able to be delivered to new consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
produced to the target node, If large messages are being delivered, the thread
In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is paused
then the Runnable of deliverLargeMessage is being run, leading to a situation
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Description:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being produced to the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being produced to the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being produced to the target
node, it can lead to message not able to be delivered to new consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
produced to the target node, If large messages are being delivered, the thread
In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is paused
then the Runnable of deliverLargeMessage is being run, leading to a situation
were the message won't be delivered to new consumers
{*}Notes{*}:
* PauseRunnable does not await for task in {{executor}} to complete,
{{deliverLargeMessage }}do create task in {{executor}}
*
** We can see that even after PauseRunnable has complete,
deliverLargeMessage's task is running after.
* If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
{{blockedOnFlowControl}} to true, before calling pause, it prevent putting new
task on executor and mitigate the issue, but It feels weird and I think there
might still be race condition
was:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being consumed by the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being consumed by the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*Resolution:*
Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
after removing consumer but before going further in the stop process
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being consumed by the target
node, it can lead to message not able to be delivered to consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
consumed by the target node, If large messages are being delivered, the
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being produced to target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Summary: CoreBridge: Duplicate message when bridge is stopped while
messages being produced to target node (was: CoreBridge: Duplicate message
when bridge is stopped while messages being consumed by target node)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> produced to target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> {{deliverLargeMessage }}do create task in {{executor}}
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4812) PageCursorInfo should be cleared on its Maps when page is marked as complete
Clebert Suconic created ARTEMIS-4812: Summary: PageCursorInfo should be cleared on its Maps when page is marked as complete Key: ARTEMIS-4812 URL: https://issues.apache.org/jira/browse/ARTEMIS-4812 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.34.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.35.0 Say you have a paged destination where there is a lazy consumer. The other queues will keep consuming, and they will mark a page as complete. However PageCursorInfo::acks and PageCursorInfo::removedReferences should be cleared upon completion otherwise they will only be GCed when the page file is removed and the entries for PageCursorInfo removed. IntObjectHashMap also keeps an array of integers in memory and it won't remove it when all elements are removed. to the reference to IntObjectHashMap has to be set to null instead of removeAllReferences. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Description:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being consumed by the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being consumed by the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*Resolution:*
Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
after removing consumer but before going further in the stop process
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being consumed by the target
node, it can lead to message not able to be delivered to consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
consumed by the target node, If large messages are being delivered, the thread
In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is paused
then the Runnable of deliverLargeMessage is being run, but as consumer has been
removed, message can't be consume by target node, and the message won't be
delivered to new consumers
{*}Notes{*}:
* PauseRunnable does not await for task in {{executor}} to complete,
{{deliverLargeMessage }}do create task in {{executor}}
*
** We can see that even after PauseRunnable has complete,
deliverLargeMessage's task is running after.
* If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
{{blockedOnFlowControl}} to true, before calling pause, it prevent putting new
task on executor and mitigate the issue, but It feels weird and I think there
might still be race condition
was:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being consumed by the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being consumed by the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*Resolution:*
Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
after removing consumer but before going further in the stop process
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being consumed by the target
node, it can lead to
[jira] [Work logged] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?focusedWorklogId=922928=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922928 ] ASF GitHub Bot logged work on AMQ-9498: --- Author: ASF GitHub Bot Created on: 11/Jun/24 09:50 Start Date: 11/Jun/24 09:50 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1229: URL: https://github.com/apache/activemq/pull/1229 Issue Time Tracking --- Worklog Id: (was: 922928) Time Spent: 40m (was: 0.5h) > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853996#comment-17853996 ] ASF subversion and git services commented on AMQ-9498: -- Commit 6bdb8e26e061318b5b4f28fb4f66586471b7177b in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=6bdb8e26e ] Merge pull request #1229 from jbonofre/AMQ-9498 AMQ-9498: Upgrade to xbean 4.25 > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853995#comment-17853995 ] ASF subversion and git services commented on AMQ-9498: -- Commit d9b795c7c4258e6511a214fef26866e71e514a0a in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=d9b795c7c ] AMQ-9498: Upgrade to xbean 4.25 > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9498) Upgrade to maven-xbean-plugin 4.25
[ https://issues.apache.org/jira/browse/AMQ-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9498. --- Resolution: Fixed > Upgrade to maven-xbean-plugin 4.25 > -- > > Key: AMQ-9498 > URL: https://issues.apache.org/jira/browse/AMQ-9498 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: message-not-deliverable.log.txt)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: message-not-deliverable.log.txt
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeARTEMIS4794Test-1.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeARTEMIS4794Test-1.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: message-not-deliverable.log.txt
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: message-not-deliverable.log.txt)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeDuplicateMessagesARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: message-not-deliverable.log.txt
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being consumed by the target
> node, it can lead to message not able to be delivered to consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> consumed by the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, but as consumer
> has been removed, message can't be consume by target node, and the message
> won't be delivered to new consumers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Description:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being consumed by the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being consumed by the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*Resolution:*
Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
after removing consumer but before going further in the stop process
*UPDATE:* When using pause instead of stop in above scenari, I get message not
being develirable anymore
{*}Summary{*}:
When a bridge is paused while *large* messages being consumed by the target
node, it can lead to message not able to be delivered to consumers.
{*}Description{*}:
When Using bridge and programmatically pausing it while messages are being
consumed by the target node, If large messages are being delivered, the thread
In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is paused
then the Runnable of deliverLargeMessage is being run, but as consumer has been
removed, message can't be consume by target node, and the message won't be
delivered to new consumers
was:
+Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
Place it under
_tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
{*}Summary{*}:
When a bridge is stopped while messages being consumed by the target node,
it can lead to duplicate messages.
{*}Description{*}:
When Using bridge and programmatically *stopping* it while messages are
being consumed by the target node, the source node fails to get the
acknowledgement from target node and messages now exists on the source and the
target node.
It appears that the "active" flag being set to false when
BridgeImpl.StopRunnable is called prevent message to be acknowledged by
_BridgeImpl::sendAcknowledged_ function
{*}Context{*}:
This bug appear in my code (a custom plugin) because is start and stop Bridge
programmatically to move messages from one node to another when some conditions
are met, if they are no longer met I want to stop the moving of messages.
*Notes:*
* Changing bridge configuration
{_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
_producerWindowSize_ parameter do not help to mitigate the issue
* Not related to large messages, i use large messages in my test to ease
reproduction
* Reproduced on 2.30 and 2.34
* Calling pause() does not create duplicate
{_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
*Resolution:*
Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
after removing consumer but before going further in the stop process
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeDuplicateMessagesARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeDuplicateMessagesARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: (was: BridgeDuplicateMessagesARTEMIS4794Test.java)
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped while messages being consumed by target node
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nmeylan updated ARTEMIS-4794:
-
Attachment: BridgeDuplicateMessagesARTEMIS4794Test.java
> CoreBridge: Duplicate message when bridge is stopped while messages being
> consumed by target node
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.30.0, 2.34.0
>Reporter: nmeylan
>Priority: Major
> Attachments: BridgeDuplicateMessagesARTEMIS4794Test.java
>
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being consumed by the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being consumed by the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
> *Resolution:*
> Maybe _StopRunnable::run_ should wait until _queue.getDeliveringCount() == 0_
> after removing consumer but before going further in the stop process
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
