[jira] [Resolved] (AMQ-9510) Upgrade to jmock 2.13.1
[ https://issues.apache.org/jira/browse/AMQ-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9510. --- Resolution: Fixed > Upgrade to jmock 2.13.1 > --- > > Key: AMQ-9510 > URL: https://issues.apache.org/jira/browse/AMQ-9510 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Test Cases >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9509) Upgrade to jetty 11.0.21
[ https://issues.apache.org/jira/browse/AMQ-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9509. --- Resolution: Fixed > Upgrade to jetty 11.0.21 > > > Key: AMQ-9509 > URL: https://issues.apache.org/jira/browse/AMQ-9509 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Transport, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9507) Upgrade to commons-daemon 1.4.0
[ https://issues.apache.org/jira/browse/AMQ-9507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9507. --- Resolution: Fixed > Upgrade to commons-daemon 1.4.0 > --- > > Key: AMQ-9507 > URL: https://issues.apache.org/jira/browse/AMQ-9507 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > 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] [Assigned] (AMQ-9514) How to set exclusive consumer for ws connector?
[
https://issues.apache.org/jira/browse/AMQ-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned AMQ-9514:
-
Assignee: Jean-Baptiste Onofré
> How to set exclusive consumer for ws connector?
> ---
>
> Key: AMQ-9514
> URL: https://issues.apache.org/jira/browse/AMQ-9514
> Project: ActiveMQ Classic
> Issue Type: Bug
> Environment: ActiveMQ versions 5.15.3 and 5.18.3
>Reporter: Ondrej Mrekaj
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Hello,
> I attempted to edit the {{broker.xml}} file as follows:
> {code:java}
>
>
>
>
>
>
> {code}
> Additionally, I modified the connection string by adding
> {{{}?consumer.exclusive=true{}}}, so it now looks like this:
>
> {code:java}
> wss://HOST:IP/queue/FOO?consumer.exclusive=true {code}
> However, the {{Exclusive}} attribute is still being set to {{{}false{}}}.
> What might be causing this issue?
> I tried this configuration in ActiveMQ versions 5.15.3 and 5.18.3. The client
> connects using the WebSocket protocol.
> Thank you.
--
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] (AMQ-9516) REST API adds unexpected byte when POSTing some messages
[ https://issues.apache.org/jira/browse/AMQ-9516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-9516: -- Fix Version/s: 5.18.5 > REST API adds unexpected byte when POSTing some messages > > > Key: AMQ-9516 > URL: https://issues.apache.org/jira/browse/AMQ-9516 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3 >Reporter: Ephemeris Lappis >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.18.5 > > > When sending messages using the REST API, some payloads are stored with an > unexpected byte (0x0A) at the end of the text. This can be verified in the > msg column field when using a JDBC persistence adapter. Sending the same > messages using a usual JMS (open-wire) connection has never the problem. This > issue is probably on the REST API's data handling... > Anyway, most of messages are correctly processed, and this random behavior is > perhaps depending on the size of the messages : for some of them the text is > around 170.000 bytes. Short messages seem not to be altered. -- 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] (AMQ-9516) REST API adds unexpected byte when POSTing some messages
[ https://issues.apache.org/jira/browse/AMQ-9516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned AMQ-9516: - Assignee: Jean-Baptiste Onofré > REST API adds unexpected byte when POSTing some messages > > > Key: AMQ-9516 > URL: https://issues.apache.org/jira/browse/AMQ-9516 > Project: ActiveMQ Classic > Issue Type: Bug >Affects Versions: 5.18.3 >Reporter: Ephemeris Lappis >Assignee: Jean-Baptiste Onofré >Priority: Major > > When sending messages using the REST API, some payloads are stored with an > unexpected byte (0x0A) at the end of the text. This can be verified in the > msg column field when using a JDBC persistence adapter. Sending the same > messages using a usual JMS (open-wire) connection has never the problem. This > issue is probably on the REST API's data handling... > Anyway, most of messages are correctly processed, and this random behavior is > perhaps depending on the size of the messages : for some of them the text is > around 170.000 bytes. Short messages seem not to be altered. -- 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-4833) Remove redundant type arguments
[ https://issues.apache.org/jira/browse/ARTEMIS-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-4833: Description: There are lots of redundant type arguments all across the code-base. These should be removed. > Remove redundant type arguments > --- > > Key: ARTEMIS-4833 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4833 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > There are lots of redundant type arguments all across the code-base. These > should be removed. -- 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-4833) Remove redundant type arguments
Justin Bertram created ARTEMIS-4833: --- Summary: Remove redundant type arguments Key: ARTEMIS-4833 URL: https://issues.apache.org/jira/browse/ARTEMIS-4833 Project: ActiveMQ Artemis Issue Type: Task Reporter: Justin Bertram Assignee: Justin Bertram -- 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-4829) Use lambdas consistently
[ https://issues.apache.org/jira/browse/ARTEMIS-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856826#comment-17856826 ] ASF subversion and git services commented on ARTEMIS-4829: -- Commit d7cf5dfa446020a8d36086d38e57aaf00781c9dd in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=d7cf5dfa44 ] ARTEMIS-4829 use lambdas consistently This commit uses lambdas or method references wherever possible. There are still a handful of places that appear like they could be changed but couldn't mainly because they use "this" and the meaning of "this" changes when using a lambda. > Use lambdas consistently > > > Key: ARTEMIS-4829 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4829 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > Any place that can use a lambda or a method reference should. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?focusedWorklogId=924000=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-924000
]
ASF GitHub Bot logged work on ARTEMIS-4831:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:27
Start Date: 21/Jun/24 14:27
Worklog Time Spent: 10m
Work Description: gemmellr opened a new pull request, #4989:
URL: https://github.com/apache/activemq-artemis/pull/4989
Always use surefure default behaviour by default: fail module build when a
test fails.
Anyone wanting to ignore failures so as to run all modules, can use the
standard surefire prop to request that, e.g:
mvn test -Dmaven.test.failure.ignore
Issue Time Tracking
---
Worklog Id: (was: 924000)
Remaining Estimate: 0h
Time Spent: 10m
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?focusedWorklogId=924003=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-924003
]
ASF GitHub Bot logged work on ARTEMIS-4831:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:27
Start Date: 21/Jun/24 14:27
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4989:
URL: https://github.com/apache/activemq-artemis/pull/4989#discussion_r1647531286
##
pom.xml:
##
@@ -861,9 +858,7 @@
1
true
- ${testFailureIgnore}
alphabetical
-
${maven.test.redirectTestOutputToFile}
Review Comment:
Not strictly related, but since both are using the standard surefire
properties it is superfluous, so when removing the other configuration element
I took this out too.
##
pom.xml:
##
@@ -861,9 +858,7 @@
1
true
- ${testFailureIgnore}
alphabetical
-
${maven.test.redirectTestOutputToFile}
Review Comment:
Not strictly related other than being the same type of cleanup; since both
are using the standard surefire properties they are superfluous, so when
removing the other configuration element I took this out too.
Issue Time Tracking
---
Worklog Id: (was: 924003)
Time Spent: 20m (was: 10m)
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923986=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923986
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:24
Start Date: 21/Jun/24 14:24
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972
Issue Time Tracking
---
Worklog Id: (was: 923986)
Time Spent: 4h 10m (was: 4h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923985=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923985
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:24
Start Date: 21/Jun/24 14:24
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2177354426
I'm actually going to merge this now...
Thanks for this.
Issue Time Tracking
---
Worklog Id: (was: 923985)
Time Spent: 4h (was: 3h 50m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923976=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923976
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:22
Start Date: 21/Jun/24 14:22
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4972:
URL: https://github.com/apache/activemq-artemis/pull/4972#discussion_r1645202926
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/SimpleAddressManager.java:
##
@@ -100,6 +104,11 @@ public boolean addBinding(final Binding binding) throws
Exception {
if (nameMap.putIfAbsent(binding.getUniqueName(), bindingAddressPair) !=
null) {
throw ActiveMQMessageBundle.BUNDLE.bindingAlreadyExists(binding);
}
+ directBindingMap.compute(binding.getAddress(), (key, value) -> {
+ Collection bindingList = value == null ? new ArrayList<>() :
value;
+ bindingList.add(binding);
Review Comment:
Yeah.. I did some testing.. I thought the compute would do a loop retry only
(I read the wrong code).
I added some testing.. and I changed your code with adding sleeps and
everything worked.. I could see the wait to lock threads.
If you could rebase against main now that I added a test to validate this?
also, you can verify check style by doing this:
mvn -Pdev install -DskipTests=true -T2
Issue Time Tracking
---
Worklog Id: (was: 923976)
Time Spent: 3h 50m (was: 3h 40m)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4814) Remove linear iteration to get direct bindings
[
https://issues.apache.org/jira/browse/ARTEMIS-4814?focusedWorklogId=923970=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923970
]
ASF GitHub Bot logged work on ARTEMIS-4814:
---
Author: ASF GitHub Bot
Created on: 21/Jun/24 14:22
Start Date: 21/Jun/24 14:22
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4972:
URL:
https://github.com/apache/activemq-artemis/pull/4972#issuecomment-2177236106
I think this can be merged.. I will leave it open for a 1 or 2 days if
anyone else wants to give some feedback, but this is +1 from me.
Issue Time Tracking
---
Worklog Id: (was: 923970)
Time Spent: 3h 40m (was: 3.5h)
> Remove linear iteration to get direct bindings
> --
>
> Key: ARTEMIS-4814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4814
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
>Affects Versions: 2.35.0
>Reporter: Josh Byster
>Priority: Minor
> Fix For: 2.36.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, with 500K+ queues, the cleanup step of {{TempQueueCleanerUpper}}
> requires invoking {{WildcardAddressManager#getDirectBindings}}, which is O(k)
> in the number of queues.
> From method profiling, this can consume up to 95% of our CPU time when
> needing to clean up many of these.
> It would be nice to make this more efficient, which shouldn't be difficult
> given the iteration just does a simple equality check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Assigned] (ARTEMIS-4832) direct test output to file by default
[
https://issues.apache.org/jira/browse/ARTEMIS-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned ARTEMIS-4832:
---
Assignee: Robbie Gemmell
> direct test output to file by default
> -
>
> Key: ARTEMIS-4832
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4832
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
>
> Currently the artemis build prints all the test stdout to the console. This
> can make it difficult to see individual results as they occur or look back
> either while the suite is running or afterwards (previously even more of an
> issue prior to ARTEMIS-4831).
> Many of the tests generate _a lot_ of output. As a result, even the small
> subset used in the PR checks is already enough to overflow the limit GitHub
> allows to occur before truncating all outpu{{monospaced text}}t and requiring
> downloading the job logs, which you need to wait until after the run has
> finished to see. Redirecting the output will allow seeing specific results
> more easily, and also relative progress of the job prior to completion. The
> PR subset is but a small fraction of the total, so e.g when running the wider
> test suite locally with lots more integration tests this is actually even
> worse as the console will typically exceed its buffer so you simply cant see
> most results at all without e.g generating the surefire report later.
> Surefire already has a dedicated property to control this behaviour, easily
> configurable via the pom (already there) or the CLI:
> {_}maven.test.redirectTestOutputToFile{_}. Set this true such that the test
> output is directed to file by default, leaving results succinctly visible on
> the console. Archive the surefire log output whenever the GHA CI job fails so
> the test output can still be inspected for a period if needed.
> Anyone that does specifically wish to have the test output still sent to the
> console can get this on request by configuring surefire when running, e.g:
> {noformat}
> mvn test -Dmaven.test.redirectTestOutputToFile=false
> {noformat}
--
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-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-4831:
Component/s: Tests
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
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-4832) direct test output to file by default
Robbie Gemmell created ARTEMIS-4832:
---
Summary: direct test output to file by default
Key: ARTEMIS-4832
URL: https://issues.apache.org/jira/browse/ARTEMIS-4832
Project: ActiveMQ Artemis
Issue Type: Task
Components: Tests
Affects Versions: 2.35.0
Reporter: Robbie Gemmell
Fix For: 2.36.0
Currently the artemis build prints all the test stdout to the console. This can
make it difficult to see individual results as they occur or look back either
while the suite is running or afterwards (previously even more of an issue
prior to ARTEMIS-4831).
Many of the tests generate _a lot_ of output. As a result, even the small
subset used in the PR checks is already enough to overflow the limit GitHub
allows to occur before truncating all outpu{{monospaced text}}t and requiring
downloading the job logs, which you need to wait until after the run has
finished to see. Redirecting the output will allow seeing specific results more
easily, and also relative progress of the job prior to completion. The PR
subset is but a small fraction of the total, so e.g when running the wider test
suite locally with lots more integration tests this is actually even worse as
the console will typically exceed its buffer so you simply cant see most
results at all without e.g generating the surefire report later.
Surefire already has a dedicated property to control this behaviour, easily
configurable via the pom (already there) or the CLI:
{_}maven.test.redirectTestOutputToFile{_}. Set this true such that the test
output is directed to file by default, leaving results succinctly visible on
the console. Archive the surefire log output whenever the GHA CI job fails so
the test output can still be inspected for a period if needed.
Anyone that does specifically wish to have the test output still sent to the
console can get this on request by configuring surefire when running, e.g:
{noformat}
mvn test -Dmaven.test.redirectTestOutputToFile=false
{noformat}
--
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
