[jira] [Work logged] (ARTEMIS-4186) Ability to set compressionLevel for compressLargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-4186?focusedWorklogId=865508&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865508 ] ASF GitHub Bot logged work on ARTEMIS-4186: --- Author: ASF GitHub Bot Created on: 14/Jun/23 11:42 Start Date: 14/Jun/23 11:42 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4384: URL: https://github.com/apache/activemq-artemis/pull/4384 Issue Time Tracking --- Worklog Id: (was: 865508) Remaining Estimate: 0h Time Spent: 10m > Ability to set compressionLevel for compressLargeMessages > - > > Key: ARTEMIS-4186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4186 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4186) Ability to set compressionLevel for compressLargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732497#comment-17732497 ] ASF subversion and git services commented on ARTEMIS-4186: -- Commit 582a689cdba77978e55dd1cc41e64f4e9bc1b167 in activemq-artemis's branch refs/heads/main from a181321 [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=582a689cdb ] ARTEMIS-4186 Ability to set compressionLevel for compressLargeMessages > Ability to set compressionLevel for compressLargeMessages > - > > Key: ARTEMIS-4186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4186 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4303) Artemis Windows Service fails to start correctly when filepath has a space
[ https://issues.apache.org/jira/browse/ARTEMIS-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Sperlazza resolved ARTEMIS-4303. - Resolution: Fixed > Artemis Windows Service fails to start correctly when filepath has a space > -- > > Key: ARTEMIS-4303 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4303 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.28.0 > Environment: Windows 10 >Reporter: Jake Sperlazza >Priority: Minor > Attachments: artemis-service.out.log, artemis-service.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > Steps to reproduce: > # Download / extract zip: > [https://activemq.apache.org/components/artemis/download/] > # run "bin/artemis create" giving it a target path which has a space e.g.: > ## ./bin/artemis create --user default --password default --require-login > /c/Program\ Files/artemis > # Install and try and start the service > ## "C:\Program Files\artemis\bin\artemis-service.exe"install > ## "C:\Program Files\artemis\bin\artemis-service.exe" start > # Notice the web console does not come up and there are errors in the logs > (as shown in attachment artemis-service.out.log) > > I believe the problem lies in line 29 of the generated artemis-service.xml > (attached), which has a unnecessarily double-escaped space character (%%20) > for the value of ARTEMIS_INSTANCE_ETC_URI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?focusedWorklogId=865542&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865542 ] ASF GitHub Bot logged work on ARTEMIS-3042: --- Author: ASF GitHub Bot Created on: 14/Jun/23 14:32 Start Date: 14/Jun/23 14:32 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4307: URL: https://github.com/apache/activemq-artemis/pull/4307#issuecomment-1591339631 @SamTV12345 I had everything ready on my build locally, building the image for me would been a couple seconds... and this made everything from scratch, including downloading the entire maven artifacts somewhere. I wouldn't have a problem if this was an additional option to build the image, meaning if I want to use the "regular" way we could just do what we have been doing so far. in that sense if you could reuse the docker files as they are now, and just call the "multi-stage" build as an option.. then I would be ok... as long as it is well documented. Issue Time Tracking --- Worklog Id: (was: 865542) Time Spent: 12h 50m (was: 12h 40m) > Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 12h 50m > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4312?focusedWorklogId=865546&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865546
]
ASF GitHub Bot logged work on ARTEMIS-4312:
---
Author: ASF GitHub Bot
Created on: 14/Jun/23 14:55
Start Date: 14/Jun/23 14:55
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4506:
URL: https://github.com/apache/activemq-artemis/pull/4506#discussion_r1229756941
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/BindingsImpl.java:
##
@@ -270,6 +270,11 @@ public Message redistribute(final Message message,
logger.debug("Message {} being copied as {}", message.getMessageID(),
copyRedistribute.getMessageID());
}
copyRedistribute.setAddress(message.getAddress());
+ for (SimpleString property : copyRedistribute.getPropertyNames()) {
Review Comment:
@jbertram I think you should rather use
coopyRedistribute.clearInternalProperties() here. and if that does not work,
there's a predicate thing that Michael Pierce introduce that should have to be
initialized.
Issue Time Tracking
---
Worklog Id: (was: 865546)
Time Spent: 20m (was: 10m)
> Duplicates with redistribution and multiple multicast queues on the same
> address
>
>
> Key: ARTEMIS-4312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4312
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider a set-up with two brokers clustered together and redistribution
> enabled and a address with about a dozen multicast subscription queues bound
> to it. If a consumer of one of those subscriptions goes offline, messages
> will begin to build up in the queue (as expected). When the consumer comes
> back online, whatever broker it attaches to first will have messages
> redistributed from the other broker in the cluster. When this redistribution
> happens the other multicast queues receive some of those redistributed
> messages (although not all of them) even though they had already received
> them previously.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4312?focusedWorklogId=865553&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865553
]
ASF GitHub Bot logged work on ARTEMIS-4312:
---
Author: ASF GitHub Bot
Created on: 14/Jun/23 15:17
Start Date: 14/Jun/23 15:17
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4506:
URL: https://github.com/apache/activemq-artemis/pull/4506#discussion_r1229795384
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/BindingsImpl.java:
##
@@ -270,6 +270,11 @@ public Message redistribute(final Message message,
logger.debug("Message {} being copied as {}", message.getMessageID(),
copyRedistribute.getMessageID());
}
copyRedistribute.setAddress(message.getAddress());
+ for (SimpleString property : copyRedistribute.getPropertyNames()) {
Review Comment:
It does work actually
Issue Time Tracking
---
Worklog Id: (was: 865553)
Time Spent: 0.5h (was: 20m)
> Duplicates with redistribution and multiple multicast queues on the same
> address
>
>
> Key: ARTEMIS-4312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4312
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Consider a set-up with two brokers clustered together and redistribution
> enabled and a address with about a dozen multicast subscription queues bound
> to it. If a consumer of one of those subscriptions goes offline, messages
> will begin to build up in the queue (as expected). When the consumer comes
> back online, whatever broker it attaches to first will have messages
> redistributed from the other broker in the cluster. When this redistribution
> happens the other multicast queues receive some of those redistributed
> messages (although not all of them) even though they had already received
> them previously.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4312?focusedWorklogId=865556&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865556
]
ASF GitHub Bot logged work on ARTEMIS-4312:
---
Author: ASF GitHub Bot
Created on: 14/Jun/23 15:18
Start Date: 14/Jun/23 15:18
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4506:
URL: https://github.com/apache/activemq-artemis/pull/4506#discussion_r1229797434
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/BindingsImpl.java:
##
@@ -270,6 +270,11 @@ public Message redistribute(final Message message,
logger.debug("Message {} being copied as {}", message.getMessageID(),
copyRedistribute.getMessageID());
}
copyRedistribute.setAddress(message.getAddress());
+ for (SimpleString property : copyRedistribute.getPropertyNames()) {
Review Comment:
I will amend your commit with the change.
Issue Time Tracking
---
Worklog Id: (was: 865556)
Time Spent: 40m (was: 0.5h)
> Duplicates with redistribution and multiple multicast queues on the same
> address
>
>
> Key: ARTEMIS-4312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4312
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Consider a set-up with two brokers clustered together and redistribution
> enabled and a address with about a dozen multicast subscription queues bound
> to it. If a consumer of one of those subscriptions goes offline, messages
> will begin to build up in the queue (as expected). When the consumer comes
> back online, whatever broker it attaches to first will have messages
> redistributed from the other broker in the cluster. When this redistribution
> happens the other multicast queues receive some of those redistributed
> messages (although not all of them) even though they had already received
> them previously.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[ https://issues.apache.org/jira/browse/ARTEMIS-4312?focusedWorklogId=865559&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865559 ] ASF GitHub Bot logged work on ARTEMIS-4312: --- Author: ASF GitHub Bot Created on: 14/Jun/23 15:21 Start Date: 14/Jun/23 15:21 Worklog Time Spent: 10m Work Description: asfgit closed pull request #4506: ARTEMIS-4312 dupes w/redistribution and multicast URL: https://github.com/apache/activemq-artemis/pull/4506 Issue Time Tracking --- Worklog Id: (was: 865559) Time Spent: 50m (was: 40m) > Duplicates with redistribution and multiple multicast queues on the same > address > > > Key: ARTEMIS-4312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4312 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Consider a set-up with two brokers clustered together and redistribution > enabled and a address with about a dozen multicast subscription queues bound > to it. If a consumer of one of those subscriptions goes offline, messages > will begin to build up in the queue (as expected). When the consumer comes > back online, whatever broker it attaches to first will have messages > redistributed from the other broker in the cluster. When this redistribution > happens the other multicast queues receive some of those redistributed > messages (although not all of them) even though they had already received > them previously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[ https://issues.apache.org/jira/browse/ARTEMIS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732582#comment-17732582 ] ASF subversion and git services commented on ARTEMIS-4312: -- Commit 3ff8419a4b0e32bff5b43997d09db9a9acc28586 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3ff8419a4b ] ARTEMIS-4312 dupes w/redistribution and multicast Multiple multicast queues on the same address can lead to duplicate messages during redistribution in a cluster. > Duplicates with redistribution and multiple multicast queues on the same > address > > > Key: ARTEMIS-4312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4312 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Consider a set-up with two brokers clustered together and redistribution > enabled and a address with about a dozen multicast subscription queues bound > to it. If a consumer of one of those subscriptions goes offline, messages > will begin to build up in the queue (as expected). When the consumer comes > back online, whatever broker it attaches to first will have messages > redistributed from the other broker in the cluster. When this redistribution > happens the other multicast queues receive some of those redistributed > messages (although not all of them) even though they had already received > them previously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732584#comment-17732584
]
Domenico Francesco Bruscino commented on ARTEMIS-4305:
--
What issue does the old message flow record cause to the cluster?
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4308) Add tests for JDBC and Paging in Soak tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4308. Resolution: Fixed > Add tests for JDBC and Paging in Soak tests > --- > > Key: ARTEMIS-4308 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4308 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
[ https://issues.apache.org/jira/browse/ARTEMIS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732622#comment-17732622 ] Clebert Suconic commented on ARTEMIS-4313: -- Notice that using page-destination FAIL and a bridge will likely retry messages out of ordering. > Bridge does not retry if destination is full when configured to FAIL > > > Key: ARTEMIS-4313 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
Clebert Suconic created ARTEMIS-4313: Summary: Bridge does not retry if destination is full when configured to FAIL Key: ARTEMIS-4313 URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.28.0 Reporter: Clebert Suconic Fix For: 2.29.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
[ https://issues.apache.org/jira/browse/ARTEMIS-4313?focusedWorklogId=865576&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865576 ] ASF GitHub Bot logged work on ARTEMIS-4313: --- Author: ASF GitHub Bot Created on: 14/Jun/23 16:51 Start Date: 14/Jun/23 16:51 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4507: URL: https://github.com/apache/activemq-artemis/pull/4507 (no comment) Issue Time Tracking --- Worklog Id: (was: 865576) Remaining Estimate: 0h Time Spent: 10m > Bridge does not retry if destination is full when configured to FAIL > > > Key: ARTEMIS-4313 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4205) Allow a database to be used to meet pluggable quorum vote locking requirements
[ https://issues.apache.org/jira/browse/ARTEMIS-4205?focusedWorklogId=865577&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865577 ] ASF GitHub Bot logged work on ARTEMIS-4205: --- Author: ASF GitHub Bot Created on: 14/Jun/23 16:56 Start Date: 14/Jun/23 16:56 Worklog Time Spent: 10m Work Description: funkyjive commented on PR #4403: URL: https://github.com/apache/activemq-artemis/pull/4403#issuecomment-1591655010 Full disclosure, I don't know each detail about the inner functioning of the JdbcSharedStateManager itself. So there may be things that I am missing. But high level differences between the approach: The JdbcSharedStateManager is written to utilize a locking mechanism more closely to the JDBC Spec Issue Time Tracking --- Worklog Id: (was: 865577) Time Spent: 1.5h (was: 1h 20m) > Allow a database to be used to meet pluggable quorum vote locking requirements > -- > > Key: ARTEMIS-4205 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4205 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: David Bennion >Priority: Minor > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Utilizing the new pluggable quorum vote locking api, implement the locking > manager using a JDBC database connection. Support for Oracle, MSSQL and > Postgres is included initially, with H2 being utilized for unit testing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732697#comment-17732697
]
Justin Bertram commented on ARTEMIS-4305:
-
For posterity's sake...
I discussed this with Ivan via Apache Slack and my initial idea to solve this
would be to add the target broker's node ID to the session's internal state and
then compare that to what it receives when it reconnects. If the two are not
equal then it can blow up the connection completely.
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4184) Bidges with concurrency not checked/cleared properly on config reload
[ https://issues.apache.org/jira/browse/ARTEMIS-4184?focusedWorklogId=865602&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865602 ] ASF GitHub Bot logged work on ARTEMIS-4184: --- Author: ASF GitHub Bot Created on: 14/Jun/23 19:56 Start Date: 14/Jun/23 19:56 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4382: URL: https://github.com/apache/activemq-artemis/pull/4382#issuecomment-1591888414 There's a conflict that needs to be resolved. Please rebase and resolve it. Thanks! Issue Time Tracking --- Worklog Id: (was: 865602) Time Spent: 20m (was: 10m) > Bidges with concurrency not checked/cleared properly on config reload > - > > Key: ARTEMIS-4184 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4184 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Bidges with concurrency not checked/cleared properly on config reload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?focusedWorklogId=865601&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865601 ] ASF GitHub Bot logged work on ARTEMIS-4185: --- Author: ASF GitHub Bot Created on: 14/Jun/23 19:56 Start Date: 14/Jun/23 19:56 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4383: URL: https://github.com/apache/activemq-artemis/pull/4383#issuecomment-1591887791 There's a conflict that needs to be resolved. Please rebase and resolve it. Thanks! Issue Time Tracking --- Worklog Id: (was: 865601) Time Spent: 20m (was: 10m) > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
[ https://issues.apache.org/jira/browse/ARTEMIS-4313?focusedWorklogId=865618&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865618 ] ASF GitHub Bot logged work on ARTEMIS-4313: --- Author: ASF GitHub Bot Created on: 14/Jun/23 21:06 Start Date: 14/Jun/23 21:06 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4507: URL: https://github.com/apache/activemq-artemis/pull/4507 Issue Time Tracking --- Worklog Id: (was: 865618) Time Spent: 20m (was: 10m) > Bridge does not retry if destination is full when configured to FAIL > > > Key: ARTEMIS-4313 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
[ https://issues.apache.org/jira/browse/ARTEMIS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732763#comment-17732763 ] ASF subversion and git services commented on ARTEMIS-4313: -- Commit ef3a91bdfb69b0b19c1448e0410f3979f6fb0904 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ef3a91bdfb ] ARTEMIS-4313 Retry Bridge when destination full and configured to FAIL > Bridge does not retry if destination is full when configured to FAIL > > > Key: ARTEMIS-4313 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?focusedWorklogId=865621&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865621 ] ASF GitHub Bot logged work on ARTEMIS-4185: --- Author: ASF GitHub Bot Created on: 14/Jun/23 21:10 Start Date: 14/Jun/23 21:10 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4383: URL: https://github.com/apache/activemq-artemis/pull/4383#issuecomment-1591989782 I got this one... Issue Time Tracking --- Worklog Id: (was: 865621) Time Spent: 0.5h (was: 20m) > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?focusedWorklogId=865625&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865625 ] ASF GitHub Bot logged work on ARTEMIS-4185: --- Author: ASF GitHub Bot Created on: 14/Jun/23 21:21 Start Date: 14/Jun/23 21:21 Worklog Time Spent: 10m Work Description: asfgit closed pull request #4383: ARTEMIS-4185 Resending compressed message uncompressed throws excepti… URL: https://github.com/apache/activemq-artemis/pull/4383 Issue Time Tracking --- Worklog Id: (was: 865625) Time Spent: 40m (was: 0.5h) > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732768#comment-17732768 ] ASF subversion and git services commented on ARTEMIS-4185: -- Commit 0f4982913fff32516a1eb50aae71b05e19debe99 in activemq-artemis's branch refs/heads/main from a181321 [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=0f4982913f ] ARTEMIS-4185 Resending compressed message uncompressed throws exception in consumer > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4184) Bidges with concurrency not checked/cleared properly on config reload
[ https://issues.apache.org/jira/browse/ARTEMIS-4184?focusedWorklogId=865627&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865627 ] ASF GitHub Bot logged work on ARTEMIS-4184: --- Author: ASF GitHub Bot Created on: 14/Jun/23 21:25 Start Date: 14/Jun/23 21:25 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4382: URL: https://github.com/apache/activemq-artemis/pull/4382#issuecomment-1592009927 I got this one as well.. Issue Time Tracking --- Worklog Id: (was: 865627) Time Spent: 0.5h (was: 20m) > Bidges with concurrency not checked/cleared properly on config reload > - > > Key: ARTEMIS-4184 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4184 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Bidges with concurrency not checked/cleared properly on config reload -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4184) Bidges with concurrency not checked/cleared properly on config reload
[
https://issues.apache.org/jira/browse/ARTEMIS-4184?focusedWorklogId=865629&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865629
]
ASF GitHub Bot logged work on ARTEMIS-4184:
---
Author: ASF GitHub Bot
Created on: 14/Jun/23 21:28
Start Date: 14/Jun/23 21:28
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4382:
URL: https://github.com/apache/activemq-artemis/pull/4382#discussion_r1230189613
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java:
##
@@ -4586,9 +4586,12 @@ private void deployReloadableConfigFromConfiguration()
throws Exception {
for (BridgeConfiguration newBridgeConfig :
configuration.getBridgeConfigurations()) {
newBridgeConfig.setParentName(newBridgeConfig.getName());
Bridge existingBridge =
clusterManager.getBridges().get(newBridgeConfig.getParentName());
+if (existingBridge == null) {
+ existingBridge =
clusterManager.getBridges().get(newBridgeConfig.getParentName() + "-0");
Review Comment:
It doesn't seem very "product" to me.. it would work somewhere
individually.. but it does not seem right to me.
Issue Time Tracking
---
Worklog Id: (was: 865629)
Time Spent: 50m (was: 40m)
> Bidges with concurrency not checked/cleared properly on config reload
> -
>
> Key: ARTEMIS-4184
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4184
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Bidges with concurrency not checked/cleared properly on config reload
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4184) Bidges with concurrency not checked/cleared properly on config reload
[
https://issues.apache.org/jira/browse/ARTEMIS-4184?focusedWorklogId=865628&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865628
]
ASF GitHub Bot logged work on ARTEMIS-4184:
---
Author: ASF GitHub Bot
Created on: 14/Jun/23 21:28
Start Date: 14/Jun/23 21:28
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4382:
URL: https://github.com/apache/activemq-artemis/pull/4382#discussion_r1230189095
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java:
##
@@ -4586,9 +4586,12 @@ private void deployReloadableConfigFromConfiguration()
throws Exception {
for (BridgeConfiguration newBridgeConfig :
configuration.getBridgeConfigurations()) {
newBridgeConfig.setParentName(newBridgeConfig.getName());
Bridge existingBridge =
clusterManager.getBridges().get(newBridgeConfig.getParentName());
+if (existingBridge == null) {
+ existingBridge =
clusterManager.getBridges().get(newBridgeConfig.getParentName() + "-0");
Review Comment:
I don't understand what is this concatenation here. is this really necessary?
Issue Time Tracking
---
Worklog Id: (was: 865628)
Time Spent: 40m (was: 0.5h)
> Bidges with concurrency not checked/cleared properly on config reload
> -
>
> Key: ARTEMIS-4184
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4184
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Bidges with concurrency not checked/cleared properly on config reload
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4155) Broker will dead lock if sending OpenWire Large Messages With Journal Retention configured.
[ https://issues.apache.org/jira/browse/ARTEMIS-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4155. Resolution: Fixed > Broker will dead lock if sending OpenWire Large Messages With Journal > Retention configured. > --- > > Key: ARTEMIS-4155 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4155 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > the LargeServerMessageImpl.asLargeMessage will check if the message is beyond > the journal buffer size and convert it to large. > if retention is used, this operation tries to make a sync operation on the > journal which will never complete because is being called within the > JournalExecutor itself. It's a server's deadlock on this case (actually > technically a starvation, but same results). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4195) Auth callback to get Client ID
[ https://issues.apache.org/jira/browse/ARTEMIS-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4195. Resolution: Fixed > Auth callback to get Client ID > -- > > Key: ARTEMIS-4195 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4195 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: JAAS >Affects Versions: 2.28.0 >Reporter: Alexey Markevich >Priority: Major > Fix For: 2.29.0 > > > Currently there is no way to get client ID in custom login module. Its > required for some MQTT cases when username is not used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4291) Some metrics do not have the "broker" tag
[
https://issues.apache.org/jira/browse/ARTEMIS-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4291.
Resolution: Fixed
> Some metrics do not have the "broker" tag
> -
>
> Key: ARTEMIS-4291
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4291
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Roelof Naude
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Some metrics do not have the "broker" tag. The "broker" may not match the
> "instance" added by e.g. prometheus, leading to a mismatch.
> [MetricsManager|https://github.com/apache/activemq-artemis/blob/2.28.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/metrics/MetricsManager.java]
> should ideally add "broker" to the common tags, e.g:
> {code:java}
> meterRegistry.config().commonTags("broker", brokerName);{code}
>
> [PR 4487|https://github.com/apache/activemq-artemis/pull/4487] was submitted
> to resolve this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4191) JournalImpl::needs compact should include more logging to enable eventual investigations
[ https://issues.apache.org/jira/browse/ARTEMIS-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4191. Resolution: Fixed > JournalImpl::needs compact should include more logging to enable eventual > investigations > > > Key: ARTEMIS-4191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4191 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4312) Duplicates with redistribution and multiple multicast queues on the same address
[ https://issues.apache.org/jira/browse/ARTEMIS-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4312. Resolution: Fixed > Duplicates with redistribution and multiple multicast queues on the same > address > > > Key: ARTEMIS-4312 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4312 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Consider a set-up with two brokers clustered together and redistribution > enabled and a address with about a dozen multicast subscription queues bound > to it. If a consumer of one of those subscriptions goes offline, messages > will begin to build up in the queue (as expected). When the consumer comes > back online, whatever broker it attaches to first will have messages > redistributed from the other broker in the cluster. When this redistribution > happens the other multicast queues receive some of those redistributed > messages (although not all of them) even though they had already received > them previously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4183) Broker diagram is not properly updated when new nodes become available
[
https://issues.apache.org/jira/browse/ARTEMIS-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4183.
Resolution: Fixed
> Broker diagram is not properly updated when new nodes become available
> --
>
> Key: ARTEMIS-4183
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4183
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Attachments: image-2023-02-26-16-36-25-761.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using an auto discovery cluster.
> When the number of nodes is reduced, the broker diagram is properly updated
> when the Refresh button is used.
> When the number of nodes is enlarged, the broker diagram is _not_ properly
> updated when the Refresh button is used. The new nodes are visible, but their
> cluster-connections are not shown. The diagram can easily be fixed by using
> the browser refresh button instead, or by temporarily switching tabs within
> the Artemis console.
> The following diagram shows the effect:
> !image-2023-02-26-16-36-25-761.png!
> left image: initial situation with 5 nodes
> middle image: 3 nodes are added, and after Refresh button is used
> right image: after page refresh
> -I know the JS code from the Console fairly well. I suspect a synchronisation
> error between the variables {{relations}} and {{{}hiddenRelations{}}}. I'll
> investigate and try to add a PR.-
> A PR is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4242) closing session with recent 'async acks' can lead to exceptions from apparent consumer cleanup race
[
https://issues.apache.org/jira/browse/ARTEMIS-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4242.
Resolution: Fixed
> closing session with recent 'async acks' can lead to exceptions from apparent
> consumer cleanup race
> ---
>
> Key: ARTEMIS-4242
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4242
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> (Title is a little bit of a guess based on what a test is doing, the
> exceptions logged as a result, and the fact it poisoned a subsequent test).
> Closing a session with recent 'async acks' from using option
> 'blockOnAcknowledge=false' appears to lead to possible exceptions on the
> broker (snippet later), seemingly from a race between consumer cleanup during
> this, and processing of the previous acknowledgements.
> AcknowledgementTest.testNonBlockingAckPerf sends messages and then consumes
> them two seperate queues with 'blockOnAcknowledge=false' and
> 'blockOnAcknowledge=true' and compares duration. When it is done consuming,
> it closes the session (but not consumer) and connection. Invariably, it logs
> stacktraces like below during execution of this test (not obvious from
> default output, but is when turning on some debug instrumentation of which
> test is starting/stopping). After this happens, the test that follows would
> fail due to finding an extra message on a queue (queue1) they both used (this
> was reported in ARTEMIS-4082 against testDupsOKAcknowledgeQueue).
> Changing AcknowledgementTest.testNonBlockingAckPerf to closely inspect the
> counts after it is main work is finished, it then fails sporadically as or
> more often than it was causing testDupsOKAcknowledgeQueue to fail. Siilarly,
> isolating testNonBlockingAckPerf to its own queues looks to stop
> testDupsOKAcknowledgeQueue sporadically failing, which is what will be done
> here initially.
> Example output during failure in recent run:
> https://github.com/apache/activemq-artemis/actions/runs/4691971133/jobs/8317110969#step:5:33384
> {noformat}
> [Thread-0
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=localhost-195163481)]
> 17:20:43,422 WARN [org.apache.activemq.artemis.core.server] AMQ222061:
> Client connection failed, clearing up resources for session
> 855206e2-da1f-11ed-8303-000d3aa462b0
> [Thread-0
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=localhost-195163481)]
> 17:20:43,430 WARN [org.apache.activemq.artemis.core.server] AMQ222107:
> Cleared up resources for session 855206e2-da1f-11ed-8303-000d3aa462b0
> [Thread-7
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@fd46303)]
> 17:20:43,446 ERROR [org.apache.activemq.artemis.core.server] AMQ224016:
> Caught exception
> org.apache.activemq.artemis.api.core.ActiveMQIllegalStateException:
> AMQ229028: Consumer 0 doesn't exist on the server
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.findConsumer(ServerSessionImpl.java:1267)
> ~[artemis-server-2.29.0-SNAPSHOT.jar:2.29.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.acknowledge(ServerSessionImpl.java:1234)
> ~[artemis-server-2.29.0-SNAPSHOT.jar:2.29.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onSessionAcknowledge(ServerSessionPacketHandler.java:762)
> ~[artemis-server-2.29.0-SNAPSHOT.jar:2.29.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:302)
> ~[artemis-server-2.29.0-SNAPSHOT.jar:2.29.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:32)
> ~[artemis-commons-2.29.0-SNAPSHOT.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.29.0-SNAPSHOT.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[artemis-commons-2.29.0-SNAPSHOT.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[artemis-commons-2.29.0-SNAPSHOT.jar:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[artemis-commons-2.29.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> ~[?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFact
[jira] [Closed] (ARTEMIS-4186) Ability to set compressionLevel for compressLargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4186. Resolution: Fixed > Ability to set compressionLevel for compressLargeMessages > - > > Key: ARTEMIS-4186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4186 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4237) Move SoakPagingTest and ReplicationFlowControlTest into soak-tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4237. Resolution: Fixed > Move SoakPagingTest and ReplicationFlowControlTest into soak-tests > -- > > Key: ARTEMIS-4237 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4237 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > These two tests were written before an actual soak-tests project existed. So > they should be moved now that there is one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3809.
Resolution: Fixed
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Priority: Major
> Labels: test-stability
> Attachments: image-2022-05-03-10-51-46-872.png
>
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes across the
> threshold to become large it appears to hang the consumer indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4285. Resolution: Fixed > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4313) Bridge does not retry if destination is full when configured to FAIL
[ https://issues.apache.org/jira/browse/ARTEMIS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4313. Resolution: Fixed > Bridge does not retry if destination is full when configured to FAIL > > > Key: ARTEMIS-4313 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4313 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4281) Queue Reaper may remove non empty queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4281. Resolution: Fixed > Queue Reaper may remove non empty queues > > > Key: ARTEMIS-4281 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4281 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > > Say you configure the auto delete queue with > .setAutoDeleteQueuesMessageCount(-1). > We shouldn't reap non empty queues during the initial reaping phase. This is > because you could have a failed over client moving to the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4297) Allow regex in no-cache exception config
[
https://issues.apache.org/jira/browse/ARTEMIS-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4297.
Resolution: Fixed
> Allow regex in no-cache exception config
>
>
> Key: ARTEMIS-4297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4297
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the {{LDAPLoginModule}} supports the ability to configure a list of
> exceptions which should skip the broker's authentication cache (see
> ARTEMIS-4101). The configuration should support regular expressions so that
> it's simpler to cover a wide range of exception types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4282) Sending Large ApplicationProperties section in a transactional session may break the server.
[ https://issues.apache.org/jira/browse/ARTEMIS-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4282. Resolution: Fixed > Sending Large ApplicationProperties section in a transactional session may > break the server. > > > Key: ARTEMIS-4282 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4282 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-2824. Resolution: Fixed > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4275. Resolution: Fixed > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4278) Incorrect Page Counters when using Prepared Transactions with Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4278. Resolution: Fixed > Incorrect Page Counters when using Prepared Transactions with Paging > > > Key: ARTEMIS-4278 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4278 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The system is not reloading the state on afterCommit for prepared > Transactions in relation to the page counters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4250) ShutdownOnCriticalIOErrorMoveNextTest failing
[ https://issues.apache.org/jira/browse/ARTEMIS-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4250. Resolution: Fixed > ShutdownOnCriticalIOErrorMoveNextTest failing > - > > Key: ARTEMIS-4250 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4250 > Project: ActiveMQ Artemis > Issue Type: Test >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ShutdownOnCriticalIOErrorMoveNextTest will simulate an IO failure, and some > of the Executors are not being cleaned. > This is an odd situation that would happen when the VM was coming down > anyway. So the test should really use a spawned VM. > The test is leaking threads, and spawning a VM would avoid these issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4175) JournalFileImpl Leaking
[ https://issues.apache.org/jira/browse/ARTEMIS-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4175. Resolution: Fixed > JournalFileImpl Leaking > --- > > Key: ARTEMIS-4175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4175 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > This is another win from Check-Leak / leak-tests > JournalFileImpl is currently leaking from negative counts. > Once a file is gone (from reusing or delete), the file negatives are never > removed. > This will make a linked list as the negatives will have negatives and they > will never be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4224) Manage memory consumption on the test suite
[
https://issues.apache.org/jira/browse/ARTEMIS-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4224.
Resolution: Fixed
> Manage memory consumption on the test suite
> ---
>
> Key: ARTEMIS-4224
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4224
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Clebert Suconic
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A lot of tests are using too much resources on the test suite. An example
> would be a compacting test unbounded using 1.5G of memory in executors
> because it is not using any syncs in the journal and it just keeps throwing
> more stuff on executors, or another case would be certain MQTTTests or
> Certificate tests.
> We should be careful and if we really must use that many resources we should
> then move the test into a soak test.
> I have recently added a few commits as NO-JIRA, which was a mistake from my
> part as I thought it was going to be an easy task but this has been extending
> as a major task.
> here is a list of commits I have added as part of this issue:
> {code:java}
> commit 41b2ec7efbc05955402ed94e2a120932dc6dab0b
> Author: Clebert Suconic
> Date: Tue Mar 28 04:38:15 2023 -0400
> NO-JIRA Limitting load on PotentialOOMELoggingTest
> commit 6de9e30c4638d8ac50d4088a65f0c700527b3ba9
> Author: Clebert Suconic
> Date: Tue Mar 28 04:33:24 2023 -0400
> NO-JIRA Limiting load on NIOJournalCompactTest
> commit 880fe86ddc35adb681832440ab589736312edd84
> Author: Clebert Suconic
> Date: Mon Mar 27 17:45:00 2023 -0400
> NO-JIRA Moving MQTT5Test::testMaxMessageSize into a soak-test
> commit d139ad75c2edff8a9ab765e907d3d6eb090492a7
> Author: Clebert Suconic
> Date: Mon Mar 27 12:30:33 2023 -0400
> NO-JIRA Allocating less memory on soak-tests
> commit 95cba558e41ab60a015c38384214d4ed20320b64
> Author: Clebert Suconic
> Date: Mon Mar 27 09:18:55 2023 -0400
> NO-JIRA Allocating less memory on soak-tests
> commit d730d1a684c6868ba24745c1ccd220c14b84c74f
> Author: Clebert Suconic
> Date: Thu Mar 16 20:36:09 2023 -0400
> NO-JIRA Testsuite speedup: proper JDBC drop from derby
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4274) Push masked credential support into core client
[
https://issues.apache.org/jira/browse/ARTEMIS-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4274.
Resolution: Fixed
> Push masked credential support into core client
> ---
>
> Key: ARTEMIS-4274
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4274
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently masked credentials are only supported in the core JMS client. This
> support should be pushed down into the core client itself so things like CLI
> utilities (e.g. {{queue stat}}, {{check node}}) can use it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4253) disabling a few ActiveMQServerControlUsingCoreTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4253. Resolution: Fixed > disabling a few ActiveMQServerControlUsingCoreTest tests > > > Key: ARTEMIS-4253 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4253 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > some of these tests are adding noise to the test. > For example you count how many sessions you have, however the framework to > send and receive notifications itself is creating a sessions. Some times > (intermittently) these sessions are affecting the counts, what makes these > tests invalid and they should be ignored on the UsingCoreTests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4185) Resending compressed message uncompressed throws exception in consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4185. Resolution: Fixed > Resending compressed message uncompressed throws exception in consumer > -- > > Key: ARTEMIS-4185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4185 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Resending compressed message uncompressed throws exception in consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4268) AMQPMessage copy constructor shouldn't copy all message annotations
[ https://issues.apache.org/jira/browse/ARTEMIS-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4268. Resolution: Fixed > AMQPMessage copy constructor shouldn't copy all message annotations > --- > > Key: ARTEMIS-4268 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4268 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > During redistribution, we should not copy all message annotations. > In particular we should not copy any of the x-opt-ORIG annotations used on > DLQ and other copies. > this was broken after f632e8104bbdae1fbf3658fec47e180784e957da (ARTEMIS-3833 > Preserve JMSCorrelationID of distributed AMQP large messages) > The change preserved too much, and as a result of that > AmqpLargeMessageRedistributionTest::testSendMessageToBroker0GetFromBroker2 is > intermittently failing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4292) Support additional Micrometer system metrics
[ https://issues.apache.org/jira/browse/ARTEMIS-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4292. Resolution: Fixed > Support additional Micrometer system metrics > > > Key: ARTEMIS-4292 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4292 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The broker already supports optional metrics for the JVM and Netty, but > Micrometer has a number of other metrics which would be useful to support as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4279) CriticalAnalyzer thread does not shut down if error during broker initialization
[ https://issues.apache.org/jira/browse/ARTEMIS-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4279. Resolution: Fixed > CriticalAnalyzer thread does not shut down if error during broker > initialization > > > Key: ARTEMIS-4279 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4279 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.29.0 >Reporter: Stephen Higgs >Priority: Major > > During broker initialization, if there is an error at a very specific time > (creating nodemanager), the broker will stop but the critical analyzer thread > will continue to run, preventing the process from exiting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4293) Add management ops to clear authn/z caches
[ https://issues.apache.org/jira/browse/ARTEMIS-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4293. Resolution: Fixed > Add management ops to clear authn/z caches > -- > > Key: ARTEMIS-4293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4293 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4211) AMQ222153: Cannot locate record in bidirectional upstream queue federation
[
https://issues.apache.org/jira/browse/ARTEMIS-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4211.
Resolution: Fixed
> AMQ222153: Cannot locate record in bidirectional upstream queue federation
> --
>
> Key: ARTEMIS-4211
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4211
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Two consumers of the same queue connected to two distinct federated brokers
> with a bidirectional upstream queue federation can cause the following error:
> {code:java}
> [Thread-12
> (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$8@3e14c16d)]
> 17:55:45,171 WARN [org.apache.activemq.artemis.core.server] AMQ222153:
> Cannot locate record for message id = 260 on Journal
> java.lang.Exception: trace
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.messageUpdateCallback(AbstractJournalStorageManager.java:461)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.core.journal.impl.JournalImpl$3.run(JournalImpl.java:1194)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> ~[classes/:?]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68)
> ~[classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> ~[classes/:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4236) Reorganize default broker.xml around paging configuration
[ https://issues.apache.org/jira/browse/ARTEMIS-4236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4236. Resolution: Fixed > Reorganize default broker.xml around paging configuration > - > > Key: ARTEMIS-4236 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4236 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4215) JournalFlush might never happen when journal-sync-* is false
[ https://issues.apache.org/jira/browse/ARTEMIS-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4215. Resolution: Fixed > JournalFlush might never happen when journal-sync-* is false > > > Key: ARTEMIS-4215 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4215 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > When journal-sync-* is false then flushes to journal will only ever happen > once the buffer is full or when the broker is cleanly shut down, regardless > of how much time passes. This means that if the broker is started with these > settings a crash/kill -9 will for sure loose messages, regardless of how much > time passes since the messages where sent. > This started with version 2.18.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4207) Redistribution may leave large messages stranded
[ https://issues.apache.org/jira/browse/ARTEMIS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4207. Resolution: Fixed > Redistribution may leave large messages stranded > > > Key: ARTEMIS-4207 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4207 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > If you are redistributing messages, eventually between the copy of the large > message and the actual call to redistribute the routing table may change, > leaving a message behind. > I could see this happening more oftenly on a test where I had 2 tests in > clustered, and one server was shutdown with Ctrl-C (SIGINT) rather than kill > -9. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3042) Official Docker Multistage Build as well as an official Docker image.
[ https://issues.apache.org/jira/browse/ARTEMIS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3042. Resolution: Fixed > Official Docker Multistage Build as well as an official Docker image. > - > > Key: ARTEMIS-3042 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3042 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: John Behm >Priority: Minor > Labels: docker,, dockerfile,, kubernetes > Time Spent: 12h 50m > Remaining Estimate: 0h > > It would be rather convenient to get people up and running with an easy to > build or to setup Docker image that automatically builds the project from > source, discards the build container and moves the necessary files over to > the final container that can simply be started. > The current docker image build is not really user firendly or convenient at > all. > > https://github.com/apache/activemq-artemis/tree/master/artemis-docker > The whole setup process of artemis in a containerized environment is very > far from even good. > The hurdle of using this software is gigantic, as the configuration is so > complex, one will not be able to do this within one month without having gone > through the whole documentation multiple times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4248) Fix PagingTest::testSimpleResume
[ https://issues.apache.org/jira/browse/ARTEMIS-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4248. Resolution: Fixed > Fix PagingTest::testSimpleResume > > > Key: ARTEMIS-4248 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4248 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > > testSimpleResume is intermittently failing. > This test is forcing another page, while cleanup is happening on the > background. > ForceAnotherPage may not put the address back into paging if this happened > right after the cleanup call. > To fix the test, we should call startPaging after forceAnotherPage is called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4190) config-delete-queues doesn't always work as expected
[
https://issues.apache.org/jira/browse/ARTEMIS-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4190.
Resolution: Fixed
> config-delete-queues doesn't always work as expected
>
>
> Key: ARTEMIS-4190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4190
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Setting config-delete-queues + config-delete-addresses seems not to work as
> expected in the use case where the original multicast address remains, but
> the fixed queues within the multicast address are moved to anycast addresses.
> Consider the following case:
> We start with two multicast addresses, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We change the addresses to move the internal queues out of the multicast
> addresses and to anycast addresses, but keeping the original multicast
> addresses themselves, like so:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> We end up with the queues remaining in the multicast addresses, along with
> new anycast queues of the same name as anycast queues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4265) Make more web console tabs conditional on permission
[
https://issues.apache.org/jira/browse/ARTEMIS-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4265.
Resolution: Fixed
> Make more web console tabs conditional on permission
>
>
> Key: ARTEMIS-4265
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4265
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Many of the tabs on the web console show up even though the user doesn't have
> permission to execute the command corresponding to the tab. For example the
> "Connections" tab shows up even though the user can't execute the
> {{listConnections}} management operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4143) Improve mitigation against split-brain with shared-storage
[ https://issues.apache.org/jira/browse/ARTEMIS-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4143. Resolution: Fixed > Improve mitigation against split-brain with shared-storage > -- > > Key: ARTEMIS-4143 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4143 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4251) Support CORE client failover to other live servers
[ https://issues.apache.org/jira/browse/ARTEMIS-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4251. Resolution: Fixed > Support CORE client failover to other live servers > -- > > Key: ARTEMIS-4251 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4251 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > The CORE clients support failover only reconnecting to the current > live/backup pair. Improve the CORE client failover connecting to other live > servers when all reconnect attempts fails, i.e. in a cluster composed of 2 > live servers, when the server to which the CORE client is connected goes down > the CORE client should reconnect its sessions to the other liver broker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4309) Large JMS ObjectMessage types result in UTFDataFormatException when deserialized on client side
[ https://issues.apache.org/jira/browse/ARTEMIS-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4309. Resolution: Fixed > Large JMS ObjectMessage types result in UTFDataFormatException when > deserialized on client side > --- > > Key: ARTEMIS-4309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4309 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: peter brady >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > When an activemq classic client uses the compression option to create a > connection with the Artemis broker, ObjectMessage types greater than 1024 > bytes have a problem being deserialized on the consumer side. The process > consuming the message attempts to reconstruct the Java object from the data > contained in the received ObjectMessage, but then throws a > UTFDataFormatException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4238) transaction timeout ActivationConfigProperty is no longer working
[ https://issues.apache.org/jira/browse/ARTEMIS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4238. Resolution: Fixed > transaction timeout ActivationConfigProperty is no longer working > - > > Key: ARTEMIS-4238 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4238 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: JMS >Affects Versions: 2.28.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > ARTEMIS-3707 has created a regression where the transactionTimeout > ActivationConfigProperty is no longer working properly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4194) Upgrade CheckLeak to 0.8
[ https://issues.apache.org/jira/browse/ARTEMIS-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4194. Resolution: Fixed > Upgrade CheckLeak to 0.8 > > > Key: ARTEMIS-4194 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4194 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4169) Auto detect dead-letter and expiry queues in the console
[ https://issues.apache.org/jira/browse/ARTEMIS-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4169. Resolution: Fixed > Auto detect dead-letter and expiry queues in the console > > > Key: ARTEMIS-4169 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4169 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The custom DLQ do not show some options/columns on hawtio. For this we have > to configure "Dead-letter address regex" on the management console. > The console browse plugin could auto-detect dead-letter and expiry queues by > checking the `_AMQ_ORIG_QUEUE` property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4254) Transactional / Replication Soak Test
[ https://issues.apache.org/jira/browse/ARTEMIS-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4254. Resolution: Fixed > Transactional / Replication Soak Test > - > > Key: ARTEMIS-4254 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4254 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > I recently developed a replication test under soak-test to validate producing > into a topic a failing over during the producers. > Even though I did not find anything wrong with the test, I am still > committing the test. (There is not enough testing, so... just one more to > ensure transaction and replication). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4259) JMS consumer + FQQN + selector not working
[
https://issues.apache.org/jira/browse/ARTEMIS-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4259.
Resolution: Fixed
> JMS consumer + FQQN + selector not working
> --
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-3640) external clients cannot use cluster topology for HA or load balancing
[
https://issues.apache.org/jira/browse/ARTEMIS-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3640.
Resolution: Fixed
> external clients cannot use cluster topology for HA or load balancing
> -
>
> Key: ARTEMIS-3640
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3640
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Vilius Šumskas
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Let's say there is a simple Artemis HA master/slave shared storage cluster
> with such configuration:
>
> {noformat}
>
> name="artemis-master">tcp://internal-cluster-dns-1:61616
> name="artemis-slave">tcp://internal-cluster-dns-2:61616
>
> {noformat}
> The cluster is using static discovery.
>
> Factory on internal clients are using:
> {noformat}
> (tcp://internal-cluster-dns-1:61616,tcp://internal-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> Those internal clients can successfully connect to the cluster and failover
> works as expected.
>
> However if there is also external clients which use external DNS/IP address
> of the cluster the topology doesn't return correct DNS name and the failover
> fails.
> {noformat}
> (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616)?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false{noformat}
> {noformat}
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:
> AMQ214033: Cannot resolve host java.net.UnknownHostException:
> internal-cluster-dns-1{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4283) Fail fast CORE client connect on closing
[ https://issues.apache.org/jira/browse/ARTEMIS-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4283. Resolution: Fixed > Fail fast CORE client connect on closing > > > Key: ARTEMIS-4283 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4283 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > ServerLocatorImpl waits for topology after connecting a new session factory. > It should interrupt waiting for topology when it is closed to fail fast. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4198) Upgrade qpid/proton-j to 0.34.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4198. Resolution: Fixed > Upgrade qpid/proton-j to 0.34.1 > --- > > Key: ARTEMIS-4198 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4198 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4244) Set web config using system properties
[ https://issues.apache.org/jira/browse/ARTEMIS-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4244. Resolution: Fixed > Set web config using system properties > -- > > Key: ARTEMIS-4244 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4244 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Set web config using system properties as users can set broker config, i.e. > starting the broker JVM with the option `-Dwebconfig.webContentEnabled=true` > enables the web content. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4252) Fix flaky QuorumFailOverTest tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4252. Resolution: Fixed > Fix flaky QuorumFailOverTest tests > -- > > Key: ARTEMIS-4252 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4252 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > QuorumFailOverTest tests are intermittently failing. To fix > QuorumFailOverTest tests, we should wait for cluster bridge connections. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4193) Interrupting Large Message Streaming with a server kill may leave orphaned files
[ https://issues.apache.org/jira/browse/ARTEMIS-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4193. Resolution: Fixed > Interrupting Large Message Streaming with a server kill may leave orphaned > files > > > Key: ARTEMIS-4193 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4193 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > There's a schema in the journal to store pending records before a file is > created. > However the sync is not properly applied and if the server is killed it could > leave a few messages orphaned in the file system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4206) Unreferenced AMQP Large Messages are not removed
[ https://issues.apache.org/jira/browse/ARTEMIS-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4206. Resolution: Fixed > Unreferenced AMQP Large Messages are not removed > > > Key: ARTEMIS-4206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4206 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Say you crashed the server after the ack, and before the file.remove, and the > journal. record removal. > The AMQP Large Message may not be removed right away, requiring a restart of > the broker. > At this point this is really caused by ARTEMIS-4193 and only affected 2.29.0 > and no previous versions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4290) Move some tests out of integration-tests into a new module where these tests will run individually
[ https://issues.apache.org/jira/browse/ARTEMIS-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4290. Resolution: Fixed > Move some tests out of integration-tests into a new module where these tests > will run individually > -- > > Key: ARTEMIS-4290 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4290 > Project: ActiveMQ Artemis > Issue Type: Test >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Some tests will leak threads affecting further tests. For these tests they > should always be forked on their own tests. > Instead of re-engineering a lot of theset tests we are creating > integrated-tests-isolated which is pretty much a copy of integration-tests > however these tests will run with forkMode=always on the maven plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4297) Allow regex in no-cache exception config
[
https://issues.apache.org/jira/browse/ARTEMIS-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reopened ARTEMIS-4297:
-
> Allow regex in no-cache exception config
>
>
> Key: ARTEMIS-4297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4297
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the {{LDAPLoginModule}} supports the ability to configure a list of
> exceptions which should skip the broker's authentication cache (see
> ARTEMIS-4101). The configuration should support regular expressions so that
> it's simpler to cover a wide range of exception types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4297) Allow regex in no-cache exception config
[
https://issues.apache.org/jira/browse/ARTEMIS-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4297:
Fix Version/s: 2.29.0
> Allow regex in no-cache exception config
>
>
> Key: ARTEMIS-4297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4297
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the {{LDAPLoginModule}} supports the ability to configure a list of
> exceptions which should skip the broker's authentication cache (see
> ARTEMIS-4101). The configuration should support regular expressions so that
> it's simpler to cover a wide range of exception types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4297) Allow regex in no-cache exception config
[
https://issues.apache.org/jira/browse/ARTEMIS-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-4297.
---
Resolution: Fixed
> Allow regex in no-cache exception config
>
>
> Key: ARTEMIS-4297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4297
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the {{LDAPLoginModule}} supports the ability to configure a list of
> exceptions which should skip the broker's authentication cache (see
> ARTEMIS-4101). The configuration should support regular expressions so that
> it's simpler to cover a wide range of exception types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4266) Mitigate NPE with bad SSL config
[
https://issues.apache.org/jira/browse/ARTEMIS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4266:
Priority: Minor (was: Major)
> Mitigate NPE with bad SSL config
>
>
> Key: ARTEMIS-4266
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4266
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an {{acceptor}} is configured with {{sslEnabled=true}} and nothing else
> the broker will thrown an NPE instead of the proper exception with the proper
> explanation of the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4266) Mitigate NPE with bad SSL config
[
https://issues.apache.org/jira/browse/ARTEMIS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4266:
Issue Type: Bug (was: Improvement)
> Mitigate NPE with bad SSL config
>
>
> Key: ARTEMIS-4266
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4266
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an {{acceptor}} is configured with {{sslEnabled=true}} and nothing else
> the broker will thrown an NPE instead of the proper exception with the proper
> explanation of the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
