[jira] [Updated] (ARTEMIS-5056) make auto-delete queues/addresses 'default' documentation clearer
[ https://issues.apache.org/jira/browse/ARTEMIS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-5056: Component/s: Documentation Affects Version/s: 2.37.0 Issue Type: Task (was: Bug) Summary: make auto-delete queues/addresses 'default' documentation clearer (was: Auto-delete queues/addresses default doesn't match documentation) > make auto-delete queues/addresses 'default' documentation clearer > - > > Key: ARTEMIS-5056 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5056 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Documentation >Affects Versions: 2.37.0 >Reporter: Vilius Šumskas >Priority: Minor > > Documentation here > [https://activemq.apache.org/components/artemis/documentation/latest/address-settings.html] > states that `auto-delete-queues` and `auto-delete-addresses` is `true` by > default however if you create a broker via CLI it is `false`. > Maybe this was an oversight in > https://issues.apache.org/jira/browse/ARTEMIS-3417 but this is very confusing > and I consider it a bug. -- 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-5056) Auto-delete queues/addresses default doesn't match documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883200#comment-17883200
]
Robbie Gemmell commented on ARTEMIS-5056:
-
It was not an oversight on ARTEMIS-3417, it is even noted in the opening
sentence of the Jira ("This is not to change defaults anywhere.. Just changing
the default broker.xml"), albeit less obviously than it perhaps could have been.
The setting _default_ value, if nothing is specified in the XML, is what that
documentation page has always been referencing (albeit you have interpretted it
a different, understandable, way). It actually is accurate in that regard. The
not-specified default setting value is true.
The 'XML config created by the CLI, by default' has it explicitly set to false
these days due to ARTEMIS-3417, because it was recognised the default gave poor
out-the-box behaviour and so the XML created was changed to configure it to be
false for new instances created going forward. The code default remained
unchanged though so as to not break behaviour for existing configs that had
existed for many many years for anyone using prior unchanged XML configs on
upgrade but who actually did want the value to be true but potentially had not
specified that.
It is not a bug in the sense of unintended behaviour. I agree it is confusing
though and the documentation could be improved to make things clearer, so I'll
leave the Jira open but tweak it a little.
> Auto-delete queues/addresses default doesn't match documentation
>
>
> Key: ARTEMIS-5056
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5056
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Vilius Šumskas
>Priority: Minor
>
> Documentation here
> [https://activemq.apache.org/components/artemis/documentation/latest/address-settings.html]
> states that `auto-delete-queues` and `auto-delete-addresses` is `true` by
> default however if you create a broker via CLI it is `false`.
> Maybe this was an oversight in
> https://issues.apache.org/jira/browse/ARTEMIS-3417 but this is very confusing
> and I consider it a bug.
--
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-5050) misc improvements to 'Broker-to-Broker Connectivity' docs/index
Robbie Gemmell created ARTEMIS-5050: --- Summary: misc improvements to 'Broker-to-Broker Connectivity' docs/index Key: ARTEMIS-5050 URL: https://issues.apache.org/jira/browse/ARTEMIS-5050 Project: ActiveMQ Artemis Issue Type: Task Components: Documentation Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 Update the 'Broker-to-Broker Connectivity' section of the documentation index. Expose the key AMQP Broker Connections functionality around Mirroring and Federation in the index to make them more visible. Move the Core-based Federation links beside the AMQP-based ones to have them nearer each other and make clearer both exist. Add Federation to the list of functionality types supported on the broker connection. Add some detail about the various examples for the AMQP based Federation. Fix (/remove) a reference to the broker distribution for an example around mirroring, as the examples are now independent. Remove a note that broker-connections could support other protocols to simplify things; there has been no movement that it will, such notes can be added if it ever does occur. -- 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] (ARTEMIS-4781) Clustering not-large AMQP message can leak Core large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4781.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> Clustering not-large AMQP message can leak Core large message file
> --
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
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] (ARTEMIS-5045) Don't change the Micrometer MeterRegistry config
[ https://issues.apache.org/jira/browse/ARTEMIS-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5045. - Fix Version/s: 2.38.0 Resolution: Fixed > Don't change the Micrometer MeterRegistry config > > > Key: ARTEMIS-5045 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5045 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 1h > Remaining Estimate: 0h > > For embedded use-cases the Micrometer MeterRegistry may be passed in from the > application and used for other meters unrelated to the broker. Therefore, the > broker should not change the config of the MeterRegistry (e.g. by adding > common tags to all meters) as the config change(s) may be incompatible with > the needs of the embedding application. -- 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-5046) Update to Groovy 4.0.23
Robbie Gemmell created ARTEMIS-5046: --- Summary: Update to Groovy 4.0.23 Key: ARTEMIS-5046 URL: https://issues.apache.org/jira/browse/ARTEMIS-5046 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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-4781) Clustering not-large AMQP message can leak Core large message file
[
https://issues.apache.org/jira/browse/ARTEMIS-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4781:
Summary: Clustering not-large AMQP message can leak Core large message file
(was: AMQP message leaking large message file)
> Clustering not-large AMQP message can leak Core large message file
> --
>
> Key: ARTEMIS-4781
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4781
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Clustering
>Affects Versions: 2.33.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Attachments: Test4781LargeMsgOnDisk.java, reproducer-output.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SETUP:
> Using a broker-cluster.
> We are producing big AMQP messages on the first node and consume them from
> the second node.
> The size of the messages is chosen so that these are around the
> min-large-message-size.
> OBSERVATION:
> For specific message sizes, the TMP files on the second node are not removed
> even when the message is consumed.
> My assumption is that this occurs for those messages that are not initially
> LARGE messsages, but which become LARGE messages due to the movement of the
> messages between the cluster nodes. During this process a few administrative
> (or informative?) message headers are added by the broker causing the message
> size to be increased so that it is now a large message.
> REPRODUCER
> The reproducer sets-up a cluster of 2 nodes and leaves the
> min-large-message-size at the default 102400 bytes.
> The reproducer sends text-messages with a text-payload between 90KiB and
> 110KiB, increasing each time with 50 bytes. this results in a range of just
> over 400 messages.
> In this scenario, 7 files are left in the large-msgs directory after test is
> completed and all software is ended. The files have file-sizes 102433 through
> 102733 bytes.
> There were no functional problems, all messages were properly produced and
> consumed.
> REPRODUCER INSTRUCTIONS
> place attached file in directory
> {{[activemq-artemis]/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp}}
> run with: {{cd tests/integration-tests && mvn
> -Dmaven.test.redirectTestOutputToFile=false -DskipIntegrationTests=false
> -Dtest="Test4781LargeMsgOnDisk" clean test}}
> the output of the reproducer is also attached.
> NOTE:
> the title+description of this issue has been updated significantly as
> initially a much more complicated scenario was described. further
> investigation has shown that it was actually a simpler scenario.
--
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] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[ https://issues.apache.org/jira/browse/ARTEMIS-4809 ]
Robbie Gemmell deleted comment on ARTEMIS-4809:
-
was (Author: jira-bot):
Commit 8b3874d613a02ce39e34bbed942d5978af94e89a in activemq-artemis's branch
refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Josh
Byster
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8b3874d613 ]
ARTEMIS-4809 Allow configuring initial queue buffer size
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.
In this commit, we introduce initial-queue-buffer-size, which defaults
to the current value of 8192. It can be set programmatically via
QueueConfiguration#setInitialQueueBufferSize(int).
Note that this must be a positive power of 2.
> 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
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 4h 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] [Closed] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed ARTEMIS-4809.
---
Fix Version/s: 2.37.0
Resolution: Fixed
> 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
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.37.0
>
> Time Spent: 4h 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] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[ https://issues.apache.org/jira/browse/ARTEMIS-4809 ]
Robbie Gemmell deleted comment on ARTEMIS-4809:
-
was (Author: jira-bot):
Commit 8b3874d613a02ce39e34bbed942d5978af94e89a in activemq-artemis's branch
refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Josh
Byster
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8b3874d613 ]
ARTEMIS-4809 Allow configuring initial queue buffer size
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.
In this commit, we introduce initial-queue-buffer-size, which defaults
to the current value of 8192. It can be set programmatically via
QueueConfiguration#setInitialQueueBufferSize(int).
Note that this must be a positive power of 2.
> 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
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 4h 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] [Reopened] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4809:
-
Assignee: Justin Bertram
> 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
>Assignee: Justin Bertram
>Priority: Minor
> Time Spent: 4h 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] [Resolved] (ARTEMIS-4954) AddressControl.pause() can pause the snf queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4954. - Resolution: Fixed > AddressControl.pause() can pause the snf queue > -- > > Key: ARTEMIS-4954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4954 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: management >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Configure 2 or more brokers in a load-balancing cluster > (message-load-balancing=ON_DEMAND for cluster connection, > redistributon-delay=0 for catch-all address). > Start consumers (preferably ones with a throttled consume rate) on multiple > addresses on one broker. > Start producers (with a higher production rate than the consumers) on the > opposite broker for the same addresses. > Wait for a little bit of message backlog to occur. > Pause one address on the broker where the producer is / was connected > We see a backlog develop in the SF queue and delivery to the consumer on the > other broker remains blocked, even after all the messages on the consumer > broker are consumed. -- 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-4954) AddressControl.pause() can pause the snf queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4954: Fix Version/s: 2.37.0 > AddressControl.pause() can pause the snf queue > -- > > Key: ARTEMIS-4954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4954 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: management >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Configure 2 or more brokers in a load-balancing cluster > (message-load-balancing=ON_DEMAND for cluster connection, > redistributon-delay=0 for catch-all address). > Start consumers (preferably ones with a throttled consume rate) on multiple > addresses on one broker. > Start producers (with a higher production rate than the consumers) on the > opposite broker for the same addresses. > Wait for a little bit of message backlog to occur. > Pause one address on the broker where the producer is / was connected > We see a backlog develop in the SF queue and delivery to the consumer on the > other broker remains blocked, even after all the messages on the consumer > broker are consumed. -- 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] [Closed] (ARTEMIS-4954) AddressControl.pause() can pause the snf queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4954. --- > AddressControl.pause() can pause the snf queue > -- > > Key: ARTEMIS-4954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4954 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: management >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Configure 2 or more brokers in a load-balancing cluster > (message-load-balancing=ON_DEMAND for cluster connection, > redistributon-delay=0 for catch-all address). > Start consumers (preferably ones with a throttled consume rate) on multiple > addresses on one broker. > Start producers (with a higher production rate than the consumers) on the > opposite broker for the same addresses. > Wait for a little bit of message backlog to occur. > Pause one address on the broker where the producer is / was connected > We see a backlog develop in the SF queue and delivery to the consumer on the > other broker remains blocked, even after all the messages on the consumer > broker are consumed. -- 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] [Reopened] (ARTEMIS-4954) AddressControl.pause() can pause the snf queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4954: - > AddressControl.pause() can pause the snf queue > -- > > Key: ARTEMIS-4954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4954 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: management >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Configure 2 or more brokers in a load-balancing cluster > (message-load-balancing=ON_DEMAND for cluster connection, > redistributon-delay=0 for catch-all address). > Start consumers (preferably ones with a throttled consume rate) on multiple > addresses on one broker. > Start producers (with a higher production rate than the consumers) on the > opposite broker for the same addresses. > Wait for a little bit of message backlog to occur. > Pause one address on the broker where the producer is / was connected > We see a backlog develop in the SF queue and delivery to the consumer on the > other broker remains blocked, even after all the messages on the consumer > broker are consumed. -- 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] (ARTEMIS-4182) allow configuring client-id for bridge and cluster connections
[ https://issues.apache.org/jira/browse/ARTEMIS-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4182. - Fix Version/s: 2.38.0 Assignee: Justin Bertram Resolution: Fixed > allow configuring client-id for bridge and cluster connections > -- > > Key: ARTEMIS-4182 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4182 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Erwin Dondorp >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > when running Artemis in a cluster, the brokers have connections between them. > these are easily identifiable in the list of connections because the "Users" > field is filled in with the username that was specified in setting > `cluster-user`. > but it is unclear where each connection goes to. > !image-2023-02-25-13-27-08-542.png! > > additional information: > the field "Client ID" is filled in with the remote hostname when using > broker-connection/amqp-connection. > wish: > (also) fill in field ClientID of the cluster connections. > e.g. with the broker-name or from a new parameter `cluster-clientid` -- 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-4182) allow configuring client-id for bridge and cluster connections
[ https://issues.apache.org/jira/browse/ARTEMIS-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4182: Summary: allow configuring client-id for bridge and cluster connections (was: fill client-id for cluster connections) > allow configuring client-id for bridge and cluster connections > -- > > Key: ARTEMIS-4182 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4182 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Broker >Affects Versions: 2.28.0 >Reporter: Erwin Dondorp >Priority: Major > Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > > when running Artemis in a cluster, the brokers have connections between them. > these are easily identifiable in the list of connections because the "Users" > field is filled in with the username that was specified in setting > `cluster-user`. > but it is unclear where each connection goes to. > !image-2023-02-25-13-27-08-542.png! > > additional information: > the field "Client ID" is filled in with the remote hostname when using > broker-connection/amqp-connection. > wish: > (also) fill in field ClientID of the cluster connections. > e.g. with the broker-name or from a new parameter `cluster-clientid` -- 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] (ARTEMIS-4978) JMX message replay from retention cannot find AMQP messages when using filters
[ https://issues.apache.org/jira/browse/ARTEMIS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4978. - Fix Version/s: 2.38.0 Assignee: Timothy A. Bish Resolution: Fixed > JMX message replay from retention cannot find AMQP messages when using filters > -- > > Key: ARTEMIS-4978 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4978 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, JMX, management >Affects Versions: 2.36.0 >Reporter: Jean-Pascal Briquet >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.38.0 > > Attachments: ReplayTest.java > > Time Spent: 20m > Remaining Estimate: 0h > > Attempting to recover messages with replay and filters fails to find AMQP > messages. > The following message properties used in filter do not match AMQP messages in > retention files : AMQTimestamp, AMQPriority, ... which cause the replay > process to be unable to restore the message. > > To reproduce, I have enhanced the existing message replay test case to verify > filter behaviour. > To run it, just replace the existing Artemis test class located in > "tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/retention" > with the provided one. > -- 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] [Comment Edited] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878885#comment-17878885 ] Robbie Gemmell edited comment on ARTEMIS-5027 at 9/3/24 1:41 PM: - Is this perhaps related to / same as ARTEMIS-5017 ? EDIT: Actually, seems like that is for 'the other side', so perhaps not. EDIT2: Actually, there is not of bridges in both directions, so again seems the same hehe. was (Author: gemmellr): Is this perhaps related to / same as ARTEMIS-5017 ? EDIT: Actually, seems like that is for 'the other side', so perhaps not. > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the atta
[jira] [Comment Edited] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878885#comment-17878885 ] Robbie Gemmell edited comment on ARTEMIS-5027 at 9/3/24 1:41 PM: - Is this perhaps related to / same as ARTEMIS-5017 ? EDIT: Actually, seems like that is for 'the other side', so perhaps not. EDIT2: Actually, there is note of bridges in both directions, so again seems the same hehe. was (Author: gemmellr): Is this perhaps related to / same as ARTEMIS-5017 ? EDIT: Actually, seems like that is for 'the other side', so perhaps not. EDIT2: Actually, there is not of bridges in both directions, so again seems the same hehe. > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local vari
[jira] [Comment Edited] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878885#comment-17878885 ] Robbie Gemmell edited comment on ARTEMIS-5027 at 9/3/24 1:35 PM: - Is this perhaps related to / same as ARTEMIS-5017 ? EDIT: Actually, seems like that is for 'the other side', so perhaps not. was (Author: gemmellr): Is this perhaps related to / same as ARTEMIS-5017 ? > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe,
[jira] [Commented] (ARTEMIS-5027) Bug Report: Memory Leak in Artemis MQ when spokes disconnect
[ https://issues.apache.org/jira/browse/ARTEMIS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878885#comment-17878885 ] Robbie Gemmell commented on ARTEMIS-5027: - Is this perhaps related to / same as ARTEMIS-5017 ? > Bug Report: Memory Leak in Artemis MQ when spokes disconnect > > > Key: ARTEMIS-5027 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5027 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.37.0 > Environment: Oracle Linux Server release 9.4, 4CPU cores, 16GB of RAM > (max JVM 10GB) >Reporter: Dragan Jankovic >Priority: Major > Attachments: G1oldGen.png, Heamspace.png > > > *Environment Details:* > * *Setup:* > * *Artemis Broker:* Version 2.37 > *Issue Description:* The setup is a hub-spokes layout with one central > Artemis (hub) and many Artemis brokers connecting to it (spokes). The brokers > are connected using core bridges between queues on the spokes and queues on > the hub. There are 10 core bridges from spoke-to-hub and 10 core bridges from > hub-to-spoke, totalling in 20 connections per spoke. There are 200 spokes in > this test. > When an Artemis spoke broker (the Artemis broker making connections to the > monitored Artemis broker) is either forcibly terminated (killed) or > gracefully stopped and then started again, we observe a significant increase > in memory usage within the hub Artemis broker. The memory consumption > increases by approximately 200MB per restarted spoke broker. This indicates a > resource/memory leak. > *Fault scenario:* After the spoke broker is restarted, the memory allocated > by the hub Artemis broker continues to grow without being released. This > increase in memory usage persists, potentially leading to memory exhaustion > over time, which could destabilize the entire system. The heap dump suggests > that the resource leak happens around the connections initiated from > hub-to-spoke direction, but this needs proving. > *Technical Details:* > * *Observations:* > * A heap memory dump was taken and analyzed. > * The issue appears to originate from the > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl class > within the Artemis broker codebase. > * This class seems to fail to release resources properly when the client > broker is terminated, likely due to unreleased connections or buffers. > *Affected version:* > * The issue is present in *Artemis 2.37* version > *Steps to Reproduce:* > # Start Artemis spoke brokers and a hub Artemis broker using the specified > versions. > # Wait for them to establish all the core bridge connections. > # Forcefully terminate (kill) or gracefully stop the Artemis spoke broker. > # Start the spoke broker again and see it re-establish the connections. > # Monitor the memory usage of the hub Artemis broker over time. > # Observe the continuous increase in memory usage > *Additional Information:* > We have created a memory dump from such a hub broker with around 450 spokes > after exhausting about 5GB of heap. > * *Memory Dump Report:* > * 144,733 instances of > org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl, loaded > by java.net.URLClassLoader @ 0x6c81acd70, occupy 4,535,785,712 (85.38%) bytes. > * Most of these instances are referenced from one instance of > java.util.HashMap$Node[], loaded by , which occupies > 141,584 (0.00%) bytes. This instance is referenced by > org.apache.activemq.artemis.core.server.cluster.ClusterManager @ 0x6c1ed4b60, > loaded by java.net.URLClassLoader @ 0x6c81acd70. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread has a local variable or > reference to > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl @ > 0x6c2c1c910, which is on the shortest path to java.util.HashMap$Node[8192] @ > 0x710f30780. > * The thread > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$FailureCheckAndFlushThread > @ 0x6c2c1c340 activemq-failure-check-thread keeps local variables with a > total size of 960 (0.00%) bytes. > * The stack trace of this thread is available and includes details of > involved local variables. > *Heap dump usage:* > The increase in heap memory is marked by rectangles in the attached pictures. -- 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] (ARTEMIS-5017) Bridge leaks ClientSessionFactory instance on reconnect attempt
[ https://issues.apache.org/jira/browse/ARTEMIS-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5017. - Fix Version/s: 2.38.0 Resolution: Fixed > Bridge leaks ClientSessionFactory instance on reconnect attempt > --- > > Key: ARTEMIS-5017 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5017 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.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-4915) TotalMessagesAdded/Acknowledged descriptions are misleading
[
https://issues.apache.org/jira/browse/ARTEMIS-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4915:
Summary: TotalMessagesAdded/Acknowledged descriptions are misleading (was:
TotalMessagesAdded/Acknowledged metrics are inaccurate if queues deleted)
> TotalMessagesAdded/Acknowledged descriptions are misleading
> ---
>
> Key: ARTEMIS-4915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4915
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMX, management
>Reporter: Josh Byster
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the total messages added/acknowledged fields are computed by
> summing up the counts on the individual queues, i.e.
> {code:java}
>@Override
>public long getTotalMessagesAdded() {
> long total = 0;
> for (Binding binding : iterableOf(postOffice.getAllBindings())) {
> if (binding.getType() == BindingType.LOCAL_QUEUE) {
> total += ((LocalQueueBinding)
> binding).getQueue().getMessagesAdded();
> }
> }
> return total;
>}
> {code}
> This fails to give an accurate count if queues are being created or deleted
> (for example, as consumers disconnect or reconnect).
> This can easily be demonstrated by sending messages and then disconnecting
> all consumers (with queue auto-deletion) and seeing the "messages added"
> count drop to 0.
--
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] (ARTEMIS-4915) TotalMessagesAdded/Acknowledged metrics are inaccurate if queues deleted
[
https://issues.apache.org/jira/browse/ARTEMIS-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4915.
-
Fix Version/s: 2.38.0
Assignee: Justin Bertram
Resolution: Fixed
> TotalMessagesAdded/Acknowledged metrics are inaccurate if queues deleted
>
>
> Key: ARTEMIS-4915
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4915
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMX, management
>Reporter: Josh Byster
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the total messages added/acknowledged fields are computed by
> summing up the counts on the individual queues, i.e.
> {code:java}
>@Override
>public long getTotalMessagesAdded() {
> long total = 0;
> for (Binding binding : iterableOf(postOffice.getAllBindings())) {
> if (binding.getType() == BindingType.LOCAL_QUEUE) {
> total += ((LocalQueueBinding)
> binding).getQueue().getMessagesAdded();
> }
> }
> return total;
>}
> {code}
> This fails to give an accurate count if queues are being created or deleted
> (for example, as consumers disconnect or reconnect).
> This can easily be demonstrated by sending messages and then disconnecting
> all consumers (with queue auto-deletion) and seeing the "messages added"
> count drop to 0.
--
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] (ARTEMIS-5026) Upgrade commons-compress to 1.27.1
[ https://issues.apache.org/jira/browse/ARTEMIS-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5026. - Fix Version/s: 2.38.0 Resolution: Fixed > Upgrade commons-compress to 1.27.1 > -- > > Key: ARTEMIS-5026 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5026 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.38.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-4957) unused value in Redistributor class
[
https://issues.apache.org/jira/browse/ARTEMIS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4957:
Priority: Trivial (was: Major)
> unused value in Redistributor class
> ---
>
> Key: ARTEMIS-4957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4957
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.23.0
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/48cd586ac59440c99d1bde9477b82c4b8c44a16b]
> there is "{*}pendingRuns"{*} variable (ReusableLatch type) , which is not
> using in class.
> How about to remove it?
--
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] (ARTEMIS-4957) unused value in Redistributor class
[
https://issues.apache.org/jira/browse/ARTEMIS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4957.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> unused value in Redistributor class
> ---
>
> Key: ARTEMIS-4957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4957
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.23.0
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/48cd586ac59440c99d1bde9477b82c4b8c44a16b]
> there is "{*}pendingRuns"{*} variable (ReusableLatch type) , which is not
> using in class.
> How about to remove it?
--
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] (ARTEMIS-4958) unused variable in AddressImpl class
[
https://issues.apache.org/jira/browse/ARTEMIS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4958.
-
Fix Version/s: 2.38.0
Resolution: Fixed
> unused variable in AddressImpl class
>
>
> Key: ARTEMIS-4958
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4958
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Trivial
> Fix For: 2.38.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/546bbfebfb7ce04b1d65039add13113d950fea88#diff-9a54e5b113b1e78b84644f0a7d408ff19904051dc956036badf90c6da8da28d6]
> there is "{*}linkedAddresses{*}" variable (List type) , which is
> not using in class.
> How about to remove it?
--
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-4958) unused variable in AddressImpl class
[
https://issues.apache.org/jira/browse/ARTEMIS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4958:
Priority: Trivial (was: Major)
> unused variable in AddressImpl class
>
>
> Key: ARTEMIS-4958
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4958
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ekaterina Zilotina
>Assignee: Justin Bertram
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> starting from [this
> commit|https://github.com/apache/activemq-artemis/commit/546bbfebfb7ce04b1d65039add13113d950fea88#diff-9a54e5b113b1e78b84644f0a7d408ff19904051dc956036badf90c6da8da28d6]
> there is "{*}linkedAddresses{*}" variable (List type) , which is
> not using in class.
> How about to remove it?
--
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] (ARTEMIS-4935) remove unused variable in ProcessBuilder.ProcessLogger
[ https://issues.apache.org/jira/browse/ARTEMIS-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4935. - Fix Version/s: 2.38.0 Resolution: Fixed > remove unused variable in ProcessBuilder.ProcessLogger > -- > > Key: ARTEMIS-4935 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4935 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Suhov Roman >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > Time Spent: 20m > Remaining Estimate: 0h > > file: > [https://github.com/apache/activemq-artemis/blob/main/artemis-cli/src/main/java/org/apache/activemq/artemis/cli/process/ProcessBuilder.java] > line: 117 > The failed field in the ProcessLogger class is unused (that is, it is > declared but not read or written to elsewhere in the code). > The failed field is initialized to false, but is not used anywhere else. > There may have been attempts in code in the past to use this field, but the > current code does not, and it remains unused. -- 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-5022) Update to selenium 4.24.0
Robbie Gemmell created ARTEMIS-5022: --- Summary: Update to selenium 4.24.0 Key: ARTEMIS-5022 URL: https://issues.apache.org/jira/browse/ARTEMIS-5022 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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-5021) Update to Mockito 5.13.0
Robbie Gemmell created ARTEMIS-5021: --- Summary: Update to Mockito 5.13.0 Key: ARTEMIS-5021 URL: https://issues.apache.org/jira/browse/ARTEMIS-5021 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Components: Tests Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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] (ARTEMIS-5019) Update to ErrorProne 2.31.0
[ https://issues.apache.org/jira/browse/ARTEMIS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5019. - Assignee: Robbie Gemmell Resolution: Fixed > Update to ErrorProne 2.31.0 > --- > > Key: ARTEMIS-5019 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5019 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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] (ARTEMIS-5020) Update maven-pmd-plugin to 3.25.0
[ https://issues.apache.org/jira/browse/ARTEMIS-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5020. - Assignee: Robbie Gemmell Resolution: Fixed > Update maven-pmd-plugin to 3.25.0 > - > > Key: ARTEMIS-5020 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5020 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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-5020) Update maven-pmd-plugin to 3.25.0
Robbie Gemmell created ARTEMIS-5020: --- Summary: Update maven-pmd-plugin to 3.25.0 Key: ARTEMIS-5020 URL: https://issues.apache.org/jira/browse/ARTEMIS-5020 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Fix For: 2.38.0 -- 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-5019) Update to ErrorProne 2.31.0
Robbie Gemmell created ARTEMIS-5019: --- Summary: Update to ErrorProne 2.31.0 Key: ARTEMIS-5019 URL: https://issues.apache.org/jira/browse/ARTEMIS-5019 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Fix For: 2.38.0 -- 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] (ARTEMIS-4906) remove Dockerfile-centos7-17, no longer builds due to repo expiry
[
https://issues.apache.org/jira/browse/ARTEMIS-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4906.
-
Fix Version/s: 2.38.0
Assignee: Justin Bertram
Resolution: Fixed
> remove Dockerfile-centos7-17, no longer builds due to repo expiry
> -
>
> Key: ARTEMIS-4906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4906
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Image
>Affects Versions: 2.35.0
>Reporter: Erwin Dondorp
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.38.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{artemis-docker/Dockerfile-centos7-17}} tries to do a "{{yum install -y
> libaio}}".
> The visible error is:
> {noformat}
> > [3/7] RUN groupadd -g 1001 -r artemis && useradd -r -u 1001 -g artemis
> artemis && yum install -y libaio && yum -y clean all:
> 0.497 Loaded plugins: fastestmirror, ovl
> 0.654 Determining fastest mirrors
> 7.170 Could not retrieve mirrorlist
> http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container
> error was
> 7.170 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown
> error"
> {noformat}
> The reason is that the repository behind this has recently been obsoleted.
> See also https://www.redhat.com/en/topics/linux/centos-linux-eol
--
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-4906) remove Dockerfile-centos7-17, no longer builds due to repo expiry
[
https://issues.apache.org/jira/browse/ARTEMIS-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4906:
Issue Type: Task (was: Bug)
> remove Dockerfile-centos7-17, no longer builds due to repo expiry
> -
>
> Key: ARTEMIS-4906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4906
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Image
>Affects Versions: 2.35.0
>Reporter: Erwin Dondorp
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{artemis-docker/Dockerfile-centos7-17}} tries to do a "{{yum install -y
> libaio}}".
> The visible error is:
> {noformat}
> > [3/7] RUN groupadd -g 1001 -r artemis && useradd -r -u 1001 -g artemis
> artemis && yum install -y libaio && yum -y clean all:
> 0.497 Loaded plugins: fastestmirror, ovl
> 0.654 Determining fastest mirrors
> 7.170 Could not retrieve mirrorlist
> http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container
> error was
> 7.170 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown
> error"
> {noformat}
> The reason is that the repository behind this has recently been obsoleted.
> See also https://www.redhat.com/en/topics/linux/centos-linux-eol
--
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-4906) remove Dockerfile-centos7-17, no longer builds due to repo expiry
[
https://issues.apache.org/jira/browse/ARTEMIS-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4906:
Summary: remove Dockerfile-centos7-17, no longer builds due to repo expiry
(was: Dockerfile-centos7-17 no longer builds due to repo expiry)
> remove Dockerfile-centos7-17, no longer builds due to repo expiry
> -
>
> Key: ARTEMIS-4906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4906
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Image
>Affects Versions: 2.35.0
>Reporter: Erwin Dondorp
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{artemis-docker/Dockerfile-centos7-17}} tries to do a "{{yum install -y
> libaio}}".
> The visible error is:
> {noformat}
> > [3/7] RUN groupadd -g 1001 -r artemis && useradd -r -u 1001 -g artemis
> artemis && yum install -y libaio && yum -y clean all:
> 0.497 Loaded plugins: fastestmirror, ovl
> 0.654 Determining fastest mirrors
> 7.170 Could not retrieve mirrorlist
> http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container
> error was
> 7.170 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown
> error"
> {noformat}
> The reason is that the repository behind this has recently been obsoleted.
> See also https://www.redhat.com/en/topics/linux/centos-linux-eol
--
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] (ARTEMIS-5007) Mirroring consumer does not recover automatically
[
https://issues.apache.org/jira/browse/ARTEMIS-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-5007.
-
Fix Version/s: 2.38.0
Assignee: Timothy A. Bish
Resolution: Fixed
> Mirroring consumer does not recover automatically
> -
>
> Key: ARTEMIS-5007
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5007
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.36.0
>Reporter: Jean-Pascal Briquet
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.38.0
>
> Attachments: testBrokerMirrorRecreateConsumer.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Context:*
> AMQP broker connection and mirroring link enabled between two Artemis nodes
> *Current behaviour:*
> The mirroring consumer does not recover automatically when it is closed from
> the administration console/JMX, or if the consumer crashes.
> This behaviour differs from the AMQP broker connection that is able to
> recover automatically if connection is closed or if connectivity fails.
> *Workaround:*
> Close the AMQP broker connection that was used by the mirroring consumer. The
> broker connection will be recreated automatically, starting a new mirroring
> consumer and restoring the replication.
> *Expected behaviour:*
> If the AMQP broker connection is active, the mirroring consumer should always
> restart if it stops or if it crashes. And at most one consumer should be
> present on the mirror/snf queue.
> This would provide to consumer a recovery identical to the AMQP broker
> connection's self-healing feature.
>
> *Tests cases:*
> Test cases are provided in attachment, to run, add them into the Artemis test
> class located under:
> tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/AMQPReplicaTest.java
> * {color:#00627a}testBrokerMirrorRecreateConsumer() : consumer closed and is
> never recreated automically{color}
> * {color:#00627a}testBrokerMirrorRecreateConnection() : broker connection
> closed and automatically recreated. The strange thing is that there is a low
> chance (10-20%) this test fails because more than 1 consumer will exists on
> the snf queue after the reconnection.
> {color}
>
--
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] (ARTEMIS-5011) update to postgresql 42.7.4
[ https://issues.apache.org/jira/browse/ARTEMIS-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5011. - Resolution: Fixed > update to postgresql 42.7.4 > --- > > Key: ARTEMIS-5011 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5011 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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-5011) update to postgresql 42.7.4
Robbie Gemmell created ARTEMIS-5011: --- Summary: update to postgresql 42.7.4 Key: ARTEMIS-5011 URL: https://issues.apache.org/jira/browse/ARTEMIS-5011 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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] (ARTEMIS-5004) AMQP Federation address bindings could be cleaned up faster
[ https://issues.apache.org/jira/browse/ARTEMIS-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5004. - Resolution: Fixed > AMQP Federation address bindings could be cleaned up faster > --- > > Key: ARTEMIS-5004 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5004 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.37.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.38.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When an AMQP Federation address consumer is closed because the local broker > no longer has demand the binding on the remote address can be removed > immediately as opposed to waiting on a scheduled cleanup. -- 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] (ARTEMIS-5005) Update to Jetty 10.0.23
[ https://issues.apache.org/jira/browse/ARTEMIS-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-5005. - Resolution: Fixed > Update to Jetty 10.0.23 > --- > > Key: ARTEMIS-5005 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5005 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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-5005) Update to Jetty 10.0.23
Robbie Gemmell created ARTEMIS-5005: --- Summary: Update to Jetty 10.0.23 Key: ARTEMIS-5005 URL: https://issues.apache.org/jira/browse/ARTEMIS-5005 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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-4986) Replication/Vote incompatibility between versions up to 2.31.2 (inclusive) and 2.32.0 - 2.36.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4986: Summary: Replication/Vote incompatibility between versions up to 2.31.2 (inclusive) and 2.32.0 - 2.36.0 (was: Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+) > Replication/Vote incompatibility between versions up to 2.31.2 (inclusive) > and 2.32.0 - 2.36.0 > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] [Closed] (ARTEMIS-4986) Replication/Vote incompatibility between versions up to 2.31.2 (inclusive) and 2.32.0 - 2.36.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4986. --- Resolution: Fixed > Replication/Vote incompatibility between versions up to 2.31.2 (inclusive) > and 2.32.0 - 2.36.0 > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4986: Affects Version/s: 2.36.0 2.35.0 2.34.0 2.33.0 > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0, 2.33.0, 2.34.0, 2.35.0, 2.36.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 4cc43323bcff16396e99ed8527a789c611515896 in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4cc43323bc ] ARTEMIS-4986 incrementing version on activemq-version.properties > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit fb7afa8ff3f1851f4501f7b004f54082e5b483c3 in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fb7afa8ff3 ] ARTEMIS-4986 Allow configuring the target destination as well > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 537e0023fc786ad947dc30c5d11c779749d0cbad in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=537e0023fc ] ARTEMIS-4986 Compatibility issue on Quorum Voting > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 10b6ab9bd3c10c202f566a4f0d55de3330e3edfe in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=10b6ab9bd3 ] ARTEMIS-4986 Providing a test that will look for the distribution from a System Variable if you define TEST_ROLLED_DISTRIBUTION=your artemis home testRollUpgrade_Provided_Distribution will execute the rolling upgrade from that distribution > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit fb7afa8ff3f1851f4501f7b004f54082e5b483c3 in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fb7afa8ff3 ] ARTEMIS-4986 Allow configuring the target destination as well > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 10b6ab9bd3c10c202f566a4f0d55de3330e3edfe in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=10b6ab9bd3 ] ARTEMIS-4986 Providing a test that will look for the distribution from a System Variable if you define TEST_ROLLED_DISTRIBUTION=your artemis home testRollUpgrade_Provided_Distribution will execute the rolling upgrade from that distribution > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 5adde5ef4352c8af126ae64eaedb800649371381 in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=5adde5ef43 ] ARTEMIS-4986 Changing plugin to compile phase to make it simpler on CI > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 537e0023fc786ad947dc30c5d11c779749d0cbad in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=537e0023fc ] ARTEMIS-4986 Compatibility issue on Quorum Voting > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 5adde5ef4352c8af126ae64eaedb800649371381 in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=5adde5ef43 ] ARTEMIS-4986 Changing plugin to compile phase to make it simpler on CI > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986 ] Robbie Gemmell deleted comment on ARTEMIS-4986: - was (Author: jira-bot): Commit 4cc43323bcff16396e99ed8527a789c611515896 in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4cc43323bc ] ARTEMIS-4986 incrementing version on activemq-version.properties > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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-4986) Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4986: Description: The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a String that was used on the wire for Voting. That string is sent on the Vote packet, and so created an incompatibility if mixing a broker <= 2.31.2 with those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they dont understand each others values. The other nodes would fail with the following message: AMQ224090: This node is not configured for Quorum Voting, all nodes must be configured for HA The server will simply not respond the VoteRequest on that case and the blockCall timeout will fail. To fix this I'm making 2.37.0+ understand both string values, and when voting against < 2.37.0 versions applying a shorter timeout that will just be ignored and cause retry with the older packet and similar short timeout in case the response wasn't found, before trying for the full timeout with the current value. The wire version will be bumped in 2.37.0 such that this process does not occur against other new 2.37.0+ brokers, which will then be known to understand the new value (and now old value). was: The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a String that was used on the wire for Voting. That string was sent on the Vote packet, and so created an incompatibility if mixing a broker <= 2.31.2 with those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they dont understand each others values. The other nodes would fail with the following message: AMQ224090: This node is not configured for Quorum Voting, all nodes must be configured for HA The server will simply not respond the VoteRequest on that case and the blockCall timeout will fail. To fix this I'm applying a shorter timeout that will just be ignored and retry with the older packet in case the response wasn't found, before trying for the full timeout with the current value. The wire version will be bumped in 2.37.0 such that this process does not occur against new brokers, which will then be known to understand both values. Summary: Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) and 2.32+ (was: Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+) > Replication/Vote incompatibility between any version up to 2.31.2 (inclusive) > and 2.32+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string is sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm making 2.37.0+ understand both string values, and when voting > against < 2.37.0 versions applying a shorter timeout that will just be > ignored and cause retry with the older packet and similar short timeout in > case the response wasn't found, before trying for the full timeout with the > current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against other new 2.37.0+ brokers, which will then be known to > understand the new value (and now old value). -- 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] [Reopened] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4986: - > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.32+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string was sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry with the older packet in case the response wasn't found, before trying > for the full timeout with the current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against new brokers, which will then be known to understand both values. -- 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] (ARTEMIS-4998) AMQP Federation target can close connection in error
[ https://issues.apache.org/jira/browse/ARTEMIS-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4998. - Resolution: Fixed > AMQP Federation target can close connection in error > > > Key: ARTEMIS-4998 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4998 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.37.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.38.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When headlining link closures from the source federation broker the target > can decide in error to close the connection when links from the source are > closed because local demand was removed, this causes an unneeded federation > rebuild. -- 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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874874#comment-17874874
]
Robbie Gemmell commented on ARTEMIS-4970:
-
I dont know what approach could work for you (beforeSend, beforeRoute,
something else) as I'm not familiar with these bits, but I am mainly suggesting
to try _not doing_ exactly what is currently being done since I think it quite
likely that consumer-time modification is what is causing the issue (you
correctly picked up the thinking behind the suggestion).
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
> Attachments: MessagePropertiesInjector.java, ioob-reload-core.log,
> ioob-target-mirror-props.log
>
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-classes-epoll-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.36.0.jar:2.36.0]
> 2024-08-06 03:44:00,596 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQ
[jira] [Updated] (ARTEMIS-4996) Update to JUnit 5.11.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4996: Fix Version/s: 2.38.0 > Update to JUnit 5.11.0 > -- > > Key: ARTEMIS-4996 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4996 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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] [Assigned] (ARTEMIS-4996) Update to JUnit 5.11.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned ARTEMIS-4996: --- Assignee: Robbie Gemmell > Update to JUnit 5.11.0 > -- > > Key: ARTEMIS-4996 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4996 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > -- 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] (ARTEMIS-4996) Update to JUnit 5.11.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4996. - Resolution: Fixed > Update to JUnit 5.11.0 > -- > > Key: ARTEMIS-4996 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4996 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > -- 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-4996) Update to JUnit 5.11.0
Robbie Gemmell created ARTEMIS-4996: --- Summary: Update to JUnit 5.11.0 Key: ARTEMIS-4996 URL: https://issues.apache.org/jira/browse/ARTEMIS-4996 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell -- 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-4970) IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent stop of message replication via mirroring
[
https://issues.apache.org/jira/browse/ARTEMIS-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874842#comment-17874842
]
Robbie Gemmell commented on ARTEMIS-4970:
-
Your new issues seem likely to be related so I'd hold off on a new Jira, as
they all stem from unexpected sizing of a Core message buffer / its data whilst
being read or written, on either side of the same link. It seems likely that
the Message buffer is being altered whilst it is being read on the outgoing
side initially.
That would also be consistent with the new information that you are actually
modifying the message on its way out of the broker with a consumer-time
delivery plugin, rather than on arrival as previously suggested. Adjusting your
plugin might help confirm that theory, i.e try actually working upon arrival
rather than exit. It may also be worth checking the property isnt already
present before you try to set it, as any property setting is considered
modification in a Core message and will cause a reencode.
> IndexOutOfBoundsException in AMQP tunnelling of Core Messages and permanent
> stop of message replication via mirroring
> -
>
> Key: ARTEMIS-4970
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4970
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Major
> Attachments: MessagePropertiesInjector.java, ioob-reload-core.log,
> ioob-target-mirror-props.log
>
>
> The IndexOutOfBoundsException error occurs randomly when messages are being
> replicated via async mirroring.
> Several thousands of messages can be replicated successfully before it
> happens.
> I have no reproduction scenario yet, as it is random but it happens several
> times per day.
> If needed, specific logging level can be enabled if that helps with the
> investigation.
> *Artemis setup:*
> The Artemis topology is composed by two Artemis clusters (of 3 groups) with
> ZK quorum (primary/backup).
> Dual async mirroring is enabled on queues on both clusters.
> *IndexOutOfBound error details*
> Most messages going through the replication link are of standard size and
> originated by Openwire or Core protocol. Large messages, averaging 150KB can
> be replicated too but are less frequent.
> Please note that the message is altered by an interceptor to add property
> "_BT_MAX_DELIVERY" when it reaches the broker.
> The message embedded in the stack trace below appears to have been
> redistributed within the cluster before being replicated, as user is
> ACTIVEMQ.CLUSTER.ADMIN.USER. I have seen it failing in non-redistributed
> scenario too.
> {noformat}
> 2024-08-06 03:44:00,596 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext]
> readerIndex: 0, writerIndex: 11960 (expected: 0 <= readerIndex <= writerIndex
> <= capacity(11715))
> java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 11960
> (expected: 0 <= readerIndex <= writerIndex <= capacity(11715))
> at
> io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135)
> ~[netty-buffer-4.1.112.Final.jar:4.1.112.Final]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPTunneledCoreMessageWriter.writeBytes(AMQPTunneledCoreMessageWriter.java:107)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:41)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.protocol.amqp.proton.MessageWriter.accept(MessageWriter.java:28)
> [artemis-amqp-protocol-2.36.0.jar:2.36.0]
> at
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
> [artemis-server-2.36.0.jar:2.36.0]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:405)
> [netty-transport-classes-epoll-4.1.112.Final.jar:4.1.112.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
> [netty-common-4.1.112.Final.jar:4.1.112.Final]
>
[jira] [Resolved] (ARTEMIS-4995) update jgroups to 5.3.11
[ https://issues.apache.org/jira/browse/ARTEMIS-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4995. - Resolution: Fixed > update jgroups to 5.3.11 > > > Key: ARTEMIS-4995 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4995 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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-4995) update jgroups to 5.3.11
Robbie Gemmell created ARTEMIS-4995: --- Summary: update jgroups to 5.3.11 Key: ARTEMIS-4995 URL: https://issues.apache.org/jira/browse/ARTEMIS-4995 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.38.0 -- 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] [Comment Edited] (ARTEMIS-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874258#comment-17874258 ] Robbie Gemmell edited comment on ARTEMIS-4973 at 8/16/24 2:47 PM: -- Commit 1f79341c05d9e512cfd41e828c00bd01ca470fbf in activemq-artemis's branch refs/heads/main from Howard Gao [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1f79341c05 ] ARTEMIS-4973 pageSizeBytes/pageLimitBytes combination can cause Address full Update docs/user-manual/paging.adoc Co-authored-by: Robbie Gemmell was (Author: jira-bot): Commit 1f79341c05d9e512cfd41e828c00bd01ca470fbf in activemq-artemis's branch refs/heads/main from Howard Gao [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1f79341c05 ] ARTEMIS-4973 pageSizeBytes/pageLimitBytes combination can cause Address full Update docs/user-manual/paging.adoc Co-authored-by: Robbie Gemmell > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- 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] (ARTEMIS-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4973. - Resolution: Fixed > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- 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-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4973: Fix Version/s: 2.37.0 > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- 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-4989) Bump slf4j.version from 2.0.13 to 2.0.16
[ https://issues.apache.org/jira/browse/ARTEMIS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4989: Fix Version/s: 2.37.0 (was: 2.38.0) > Bump slf4j.version from 2.0.13 to 2.0.16 > > > Key: ARTEMIS-4989 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4989 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- 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-4992) Bump org.codehaus.mojo:exec-maven-plugin from 3.3.0 to 3.4.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4992: Fix Version/s: 2.37.0 (was: 2.38.0) > Bump org.codehaus.mojo:exec-maven-plugin from 3.3.0 to 3.4.1 > > > Key: ARTEMIS-4992 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4992 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- 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-4991) Bump io.micrometer:micrometer-core from 1.13.2 to 1.13.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4991: Fix Version/s: 2.37.0 (was: 2.38.0) > Bump io.micrometer:micrometer-core from 1.13.2 to 1.13.3 > > > Key: ARTEMIS-4991 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4991 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- 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-4990) Bump selenium.version from 4.23.0 to 4.23.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4990: Fix Version/s: 2.37.0 (was: 2.38.0) > Bump selenium.version from 4.23.0 to 4.23.1 > --- > > Key: ARTEMIS-4990 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4990 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- 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-4994) update to Spring 5.3.39
[ https://issues.apache.org/jira/browse/ARTEMIS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4994: Fix Version/s: 2.37.0 (was: 2.38.0) > update to Spring 5.3.39 > --- > > Key: ARTEMIS-4994 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4994 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- 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] (ARTEMIS-4989) Bump slf4j.version from 2.0.13 to 2.0.16
[ https://issues.apache.org/jira/browse/ARTEMIS-4989 ] Robbie Gemmell deleted comment on ARTEMIS-4989: - was (Author: jira-bot): Commit 4092b8f4815200148d17c3c3ce1eded2b4ae6a1d in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from dependabot[bot] [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4092b8f481 ] ARTEMIS-4989 Bump slf4j.version from 2.0.13 to 2.0.16 Bumps `slf4j.version` from 2.0.13 to 2.0.16. Updates `org.slf4j:slf4j-simple` from 2.0.13 to 2.0.16 Updates `org.slf4j:slf4j-nop` from 2.0.13 to 2.0.16 Updates `org.slf4j:slf4j-api` from 2.0.13 to 2.0.16 --- updated-dependencies: - dependency-name: org.slf4j:slf4j-simple dependency-type: direct:production update-type: version-update:semver-patch - dependency-name: org.slf4j:slf4j-nop dependency-type: direct:production update-type: version-update:semver-patch - dependency-name: org.slf4j:slf4j-api dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] > Bump slf4j.version from 2.0.13 to 2.0.16 > > > Key: ARTEMIS-4989 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4989 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.38.0 > > -- 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] (ARTEMIS-4994) update to Spring 5.3.39
[ https://issues.apache.org/jira/browse/ARTEMIS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4994. - Assignee: Robbie Gemmell Resolution: Fixed > update to Spring 5.3.39 > --- > > Key: ARTEMIS-4994 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4994 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.38.0 > > -- 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-4994) update to Spring 5.3.39
Robbie Gemmell created ARTEMIS-4994: --- Summary: update to Spring 5.3.39 Key: ARTEMIS-4994 URL: https://issues.apache.org/jira/browse/ARTEMIS-4994 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Fix For: 2.38.0 -- 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-4785) Isolate broker run command Log4j and profile config from other CLI commands
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4785: Description: Isolate the broker 'run' command Log4j and profile from the other CLI commands, such that the logging configs dont interfere with each others execution, and other commands can be conigured differently than the run command. See also sub-tasks: ARTEMIS-4702 and ARTEMIS-4974 Original description: = I have come across a strange issue where the root cause is the instance dir cli sharing the log4j config with the broker. the logging has a rolling file appender schedual of 1 minute. looks to be working fine, then use instance-dir/bin/artemis produicer --user invalid to generate logging... and the broker appender gets borked. The problem, the cli is reading the same log4j2 config from the etc dir on the classpath. This is not ideal. One workaroud is to use the installation dir artemis for producer!consumer commands. I wonder if we should use -Dlog4j.configuration to specify a file not on the classpath for the broker. and leave etc off the classpath? I guess there are a few ways to solve this. but there is indeed a gotcha here. thoughts? was: I have come across a strange issue where the root cause is the instance dir cli sharing the log4j config with the broker. the logging has a rolling file appender schedual of 1 minute. looks to be working fine, then use instance-dir/bin/artemis produicer --user invalid to generate logging... and the broker appender gets borked. The problem, the cli is reading the same log4j2 config from the etc dir on the classpath. This is not ideal. One workaroud is to use the installation dir artemis for producer!consumer commands. I wonder if we should use -Dlog4j.configuration to specify a file not on the classpath for the broker. and leave etc off the classpath? I guess there are a few ways to solve this. but there is indeed a gotcha here. thoughts? Summary: Isolate broker run command Log4j and profile config from other CLI commands (was: log4j config from classpath and cli issue) > Isolate broker run command Log4j and profile config from other CLI commands > --- > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Isolate the broker 'run' command Log4j and profile from the other CLI > commands, such that the logging configs dont interfere with each others > execution, and other commands can be conigured differently than the run > command. > See also sub-tasks: ARTEMIS-4702 and ARTEMIS-4974 > > Original description: > = > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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] [Closed] (ARTEMIS-4785) Isolate broker run command Log4j and profile config from other CLI commands
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed ARTEMIS-4785. --- Resolution: Fixed > Isolate broker run command Log4j and profile config from other CLI commands > --- > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Isolate the broker 'run' command Log4j and profile from the other CLI > commands, such that the logging configs dont interfere with each others > execution, and other commands can be conigured differently than the run > command. > See also sub-tasks: ARTEMIS-4702 and ARTEMIS-4974 > > Original description: > = > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785 ] Robbie Gemmell deleted comment on ARTEMIS-4785: - was (Author: jira-bot): Commit 7cf6b86bc56e3a0a36ee055576ad6f11a9c38b14 in activemq-artemis's branch refs/heads/dependabot/maven/io.micrometer-micrometer-core-1.13.3 from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7cf6b86bc5 ] ARTEMIS-4785 ARTEMIS-4702 Add profile and log4j2 files for non-run CLI commands The run command uses the artemis.profile and log4j2.properties files while all other CLI commands use the artemis-utility.profile and log4j2-default.properties files. > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785 ] Robbie Gemmell deleted comment on ARTEMIS-4785: - was (Author: jira-bot): Commit 7cf6b86bc56e3a0a36ee055576ad6f11a9c38b14 in activemq-artemis's branch refs/heads/dependabot/maven/org.codehaus.mojo-exec-maven-plugin-3.4.1 from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7cf6b86bc5 ] ARTEMIS-4785 ARTEMIS-4702 Add profile and log4j2 files for non-run CLI commands The run command uses the artemis.profile and log4j2.properties files while all other CLI commands use the artemis-utility.profile and log4j2-default.properties files. > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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] [Reopened] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4785: - > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4986. - Resolution: Fixed > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.32+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string was sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry with the older packet in case the response wasn't found, before trying > for the full timeout with the current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against new brokers, which will then be known to understand both values. -- 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-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4986: Description: The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a String that was used on the wire for Voting. That string was sent on the Vote packet, and so created an incompatibility if mixing a broker <= 2.31.2 with those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they dont understand each others values. The other nodes would fail with the following message: AMQ224090: This node is not configured for Quorum Voting, all nodes must be configured for HA The server will simply not respond the VoteRequest on that case and the blockCall timeout will fail. To fix this I'm applying a shorter timeout that will just be ignored and retry with the older packet in case the response wasn't found, before trying for the full timeout with the current value. The wire version will be bumped in 2.37.0 such that this process does not occur against new brokers, which will then be known to understand both values. was: The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String that was used on the wire for Voting. That string was sent on the Vote and the other nodes would fail with the following message: AMQ224090: This node is not configured for Quorum Voting, all nodes must be configured for HA The server will simply not respond the VoteRequest on that case and the blockCall timeout will fail. To fix this I'm applying a shorter timeout that will just be ignored and retry at the older packet in case the response wasn't found. I was trying to play with Wire versioning but that scenario turned out to be more complex. > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.32+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string was sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry with the older packet in case the response wasn't found, before trying > for the full timeout with the current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against new brokers, which will then be known to understand both values. -- 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-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated ARTEMIS-4986: Summary: Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+ (was: Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.33+) > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.32+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- 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] [Reopened] (ARTEMIS-4986) Replication/Vote incompatibility between 2.30 and 2.31+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened ARTEMIS-4986: - > Replication/Vote incompatibility between 2.30 and 2.31+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- 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] (ARTEMIS-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-4702.
-
Resolution: Fixed
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{{}queue stat{}}}, {{{}consumer{}}},
> {{{}producer{}}}, etc. commands as well. At best, it's overkill to use 8G of
> memory for these secondary commands and at worst it can actually prevent them
> from operating at all (e.g. if the machine is low on memory).
> Add a utility profile for the commands other than 'run' to use for their own
> settings (and logging config, see ARTEMIS-4785)
--
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] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4785. - Fix Version/s: 2.37.0 Resolution: Fixed > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- 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-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4702:
Description:
Right now every {{artemis}} command uses the same JVM settings from
{{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
-Xmx8G}} for running the broker (i.e. the {{run}} command) those same settings
would be used for the {{{}queue stat{}}}, {{{}consumer{}}}, {{{}producer{}}},
etc. commands as well. At best, it's overkill to use 8G of memory for these
secondary commands and at worst it can actually prevent them from operating at
all (e.g. if the machine is low on memory).
Add a utility profile for the commands other than 'run' to use for their own
settings (and logging config, see ARTEMIS-4785)
was:
Right now every {{artemis}} command uses the same JVM settings from
{{artemis.profile}}. So, for example, if the settings included {{-Xms8G
-Xmx8G}} for running the broker (i.e. the {{run}} command) those same settings
would be used for the {{queue stat}}, {{consumer}}, {{producer}}, etc. commands
as well. At best, it's overkill to use 8G of memory for these secondary
commands and at worst it can actually prevent them from operating at all (e.g.
if the machine is low on memory).
JVM settings really only need to apply to the {{run}} command.
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{{}queue stat{}}}, {{{}consumer{}}},
> {{{}producer{}}}, etc. commands as well. At best, it's overkill to use 8G of
> memory for these secondary commands and at worst it can actually prevent them
> from operating at all (e.g. if the machine is low on memory).
> Add a utility profile for the commands other than 'run' to use for their own
> settings (and logging config, see ARTEMIS-4785)
--
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-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4702:
Fix Version/s: 2.37.0
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{artemis.profile}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{queue stat}}, {{consumer}}, {{producer}},
> etc. commands as well. At best, it's overkill to use 8G of memory for these
> secondary commands and at worst it can actually prevent them from operating
> at all (e.g. if the machine is low on memory).
> JVM settings really only need to apply to the {{run}} command.
--
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] [Reopened] (ARTEMIS-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened ARTEMIS-4702:
-
Assignee: Domenico Francesco Bruscino (was: Justin Bertram)
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{artemis.profile}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{queue stat}}, {{consumer}}, {{producer}},
> etc. commands as well. At best, it's overkill to use 8G of memory for these
> secondary commands and at worst it can actually prevent them from operating
> at all (e.g. if the machine is low on memory).
> JVM settings really only need to apply to the {{run}} command.
--
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-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4702:
Summary: Add utility profile for CLI commands other than run (was: Only
run command needs custom JVM settings)
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{artemis.profile}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{queue stat}}, {{consumer}}, {{producer}},
> etc. commands as well. At best, it's overkill to use 8G of memory for these
> secondary commands and at worst it can actually prevent them from operating
> at all (e.g. if the machine is low on memory).
> JVM settings really only need to apply to the {{run}} command.
--
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-4986) Replication/Vote incompatibility between 2.30 and 2.31+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873532#comment-17873532 ] Robbie Gemmell commented on ARTEMIS-4986: - As I mentioned on the PR, since the problem change from ARTEMIS-3474 was only included from 2.32.0 the title doesnt make sense to me, the compatibility issue should be between <= 2.31.2 and 2.32.0-2.36.0 > Replication/Vote incompatibility between 2.30 and 2.31+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- 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-4984) Update to ErrorProne 2.30.0
Robbie Gemmell created ARTEMIS-4984: --- Summary: Update to ErrorProne 2.30.0 Key: ARTEMIS-4984 URL: https://issues.apache.org/jira/browse/ARTEMIS-4984 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 2.37.0 -- 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] (ARTEMIS-4982) AMQP Large message files not removed immediately on failed sends
[ https://issues.apache.org/jira/browse/ARTEMIS-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4982. - Resolution: Fixed > AMQP Large message files not removed immediately on failed sends > > > Key: ARTEMIS-4982 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4982 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.36.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.37.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When an incoming large message is rejected for any reason the large message > file is not cleaned up immediately as it should be. -- 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] (ARTEMIS-4981) update commons-lang3 to 3.16.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4981. - Resolution: Fixed > update commons-lang3 to 3.16.0 > -- > > Key: ARTEMIS-4981 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4981 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- 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
