[jira] [Assigned] (ARTEMIS-5038) Mirror ACKs are broken if using multiple priorities
[ https://issues.apache.org/jira/browse/ARTEMIS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reassigned ARTEMIS-5038: Assignee: Clebert Suconic > Mirror ACKs are broken if using multiple priorities > --- > > Key: ARTEMIS-5038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5038 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.37.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5038) Mirror ACKs are broken if using multiple priorities
[ https://issues.apache.org/jira/browse/ARTEMIS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic resolved ARTEMIS-5038. -- Resolution: Fixed > Mirror ACKs are broken if using multiple priorities > --- > > Key: ARTEMIS-5038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5038 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.37.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5069) Sends are still hitting the mirror target on temporary queues
Clebert Suconic created ARTEMIS-5069: Summary: Sends are still hitting the mirror target on temporary queues Key: ARTEMIS-5069 URL: https://issues.apache.org/jira/browse/ARTEMIS-5069 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.38.0 on ARTEMIS-5068 I fixed the create queues for temporary queues should not hit the target server. However the sends of the messages will still be sent through the MirrorSNF, hit the server and not find anything. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5068) Temporary Queues should not be mirrored
[ https://issues.apache.org/jira/browse/ARTEMIS-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-5068: - Summary: Temporary Queues should not be mirrored (was: Temporary And Non Durable Queues should not be mirrored) > Temporary Queues should not be mirrored > --- > > Key: ARTEMIS-5068 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5068 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5068) Temporary And Non Durable Queues should not be mirrored
Clebert Suconic created ARTEMIS-5068: Summary: Temporary And Non Durable Queues should not be mirrored Key: ARTEMIS-5068 URL: https://issues.apache.org/jira/browse/ARTEMIS-5068 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5067) Race on Mirror while one side is connected while the other is not
Clebert Suconic created ARTEMIS-5067: Summary: Race on Mirror while one side is connected while the other is not Key: ARTEMIS-5067 URL: https://issues.apache.org/jira/browse/ARTEMIS-5067 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.37.0 Reporter: Clebert Suconic Fix For: 2.38.0 you send a message on mirror Source.. Source connects to target, but target still trying to connect back. a message send to target will bounce back as a new message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5066) Diverts should not be applied on mirror
Clebert Suconic created ARTEMIS-5066: Summary: Diverts should not be applied on mirror Key: ARTEMIS-5066 URL: https://issues.apache.org/jira/browse/ARTEMIS-5066 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Fix For: 2.38.0 Instead of applying Diverts on Mirror Target, we should just send the operations after the fact. Right now if you have a non exclusive divert, the messages will be duplicated.. one from the afterSend event, another for the actual routing of the divert on the targets resulting in messages that will not be removed from the ACK Manager and duplicates. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5065) We should remove mirror properties for Core and OpenWire Protocols upon receiving them on the server
[ https://issues.apache.org/jira/browse/ARTEMIS-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-5065: - Fix Version/s: 2.38.0 > We should remove mirror properties for Core and OpenWire Protocols upon > receiving them on the server > > > Key: ARTEMIS-5065 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5065 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > > say a consumer received a message from a target mirror using Core or OpenWire > Protocol. > The message will contain properties that would be hidden if using AMQP > Protocol. > Upon receiving them the server should remove them to avoid retagging them > with the older values. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5065) We should remove mirror properties for Core and OpenWire Protocols upon receiving them on the server
Clebert Suconic created ARTEMIS-5065: Summary: We should remove mirror properties for Core and OpenWire Protocols upon receiving them on the server Key: ARTEMIS-5065 URL: https://issues.apache.org/jira/browse/ARTEMIS-5065 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic say a consumer received a message from a target mirror using Core or OpenWire Protocol. The message will contain properties that would be hidden if using AMQP Protocol. Upon receiving them the server should remove them to avoid retagging them with the older values. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-4971) AckManager "giving up" processing of Acks in warning log level
[
https://issues.apache.org/jira/browse/ARTEMIS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883941#comment-17883941
]
Clebert Suconic edited comment on ARTEMIS-4971 at 9/23/24 5:04 PM:
---
[~jpbriquet]I have minimized the number of ocurrencies the unack would happen.
Since there are cases where it's ok to miss an ACK, I am adding a configuration
option to log.warn when missed.
Say if you have consumers on the target queue, you could have a legal case of a
missed ack.
was (Author: clebertsuconic):
[~jpbriquet]I have minimized the number of ocurrencies the unack would happen.
But in case it happens I will now log.warn
although there are a few cases where it's expected to not ACK.. like after a
failure.. etc...
But that's what a warn is... a WARN.. it could be ok in certain cases.
> AckManager "giving up" processing of Acks in warning log level
> --
>
> Key: ARTEMIS-4971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Minor
> Fix For: 2.38.0
>
>
> Within the AMQP AckManager, the following log message, currently at DEBUG
> level, should be increased to WARN level:
> {code:java}
> logger.debug("Retried {} {} times, giving up on the entry now", retry,
> retry.getPageAttempts());{code}
> Setting this log to WARN level would allow operators to be aware of two
> things:
> - The AckManager may require configuration tuning of queue/page attempts.
> This can easily occur with the default configuration when handling large
> messages.
> - Missed message replication, which is crucial when replication is required,
> allowing operators to investigate the source of the problem.
> The downside is that this change may trigger a large number of logs when
> enabled on Artemis nodes containing messages created before the mirroring
> configuration activation.
> This might not be desirable for everyone, so it could be beneficial to have
> it enabled as an optional parameter, configurable via a system environment
> variable, similar to the fine-tuning options available for AckManager.
> Ideally, the log should as well contain the queue name, which would allow to
> track down the source of messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4971) AckManager "giving up" processing of Acks in warning log level
[
https://issues.apache.org/jira/browse/ARTEMIS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883941#comment-17883941
]
Clebert Suconic commented on ARTEMIS-4971:
--
[~jpbriquet]I have minimized the number of ocurrencies the unack would happen.
But in case it happens I will now log.warn
although there are a few cases where it's expected to not ACK.. like after a
failure.. etc...
But that's what a warn is... a WARN.. it could be ok in certain cases.
> AckManager "giving up" processing of Acks in warning log level
> --
>
> Key: ARTEMIS-4971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Minor
> Fix For: 2.38.0
>
>
> Within the AMQP AckManager, the following log message, currently at DEBUG
> level, should be increased to WARN level:
> {code:java}
> logger.debug("Retried {} {} times, giving up on the entry now", retry,
> retry.getPageAttempts());{code}
> Setting this log to WARN level would allow operators to be aware of two
> things:
> - The AckManager may require configuration tuning of queue/page attempts.
> This can easily occur with the default configuration when handling large
> messages.
> - Missed message replication, which is crucial when replication is required,
> allowing operators to investigate the source of the problem.
> The downside is that this change may trigger a large number of logs when
> enabled on Artemis nodes containing messages created before the mirroring
> configuration activation.
> This might not be desirable for everyone, so it could be beneficial to have
> it enabled as an optional parameter, configurable via a system environment
> variable, similar to the fine-tuning options available for AckManager.
> Ideally, the log should as well contain the queue name, which would allow to
> track down the source of messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Reopened] (ARTEMIS-4971) AckManager "giving up" processing of Acks in warning log level
[
https://issues.apache.org/jira/browse/ARTEMIS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic reopened ARTEMIS-4971:
--
Assignee: Clebert Suconic
> AckManager "giving up" processing of Acks in warning log level
> --
>
> Key: ARTEMIS-4971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Assignee: Clebert Suconic
>Priority: Minor
> Fix For: 2.38.0
>
>
> Within the AMQP AckManager, the following log message, currently at DEBUG
> level, should be increased to WARN level:
> {code:java}
> logger.debug("Retried {} {} times, giving up on the entry now", retry,
> retry.getPageAttempts());{code}
> Setting this log to WARN level would allow operators to be aware of two
> things:
> - The AckManager may require configuration tuning of queue/page attempts.
> This can easily occur with the default configuration when handling large
> messages.
> - Missed message replication, which is crucial when replication is required,
> allowing operators to investigate the source of the problem.
> The downside is that this change may trigger a large number of logs when
> enabled on Artemis nodes containing messages created before the mirroring
> configuration activation.
> This might not be desirable for everyone, so it could be beneficial to have
> it enabled as an optional parameter, configurable via a system environment
> variable, similar to the fine-tuning options available for AckManager.
> Ideally, the log should as well contain the queue name, which would allow to
> track down the source of messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5038) Mirror ACKs are broken if using multiple priorities
[ https://issues.apache.org/jira/browse/ARTEMIS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-5038: - Summary: Mirror ACKs are broken if using multiple priorities (was: Concurrent access issues on LinkedListImpl) > Mirror ACKs are broken if using multiple priorities > --- > > Key: ARTEMIS-5038 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5038 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.37.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5016) Memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879953#comment-17879953 ] Clebert Suconic commented on ARTEMIS-5016: -- Without a reproducer to the issue you are seeing there's no way we can help you. Most likely your are not consuming messages... or you are not configuring paging accordingly. With such a wide scope your question falls on the scope of a consulting job where someone would need to gather more information. If you want us to take a look you will need to provide a reproducer to the issue you are seeing. Such a generic question is impossible to be addressed. > Memory not getting released > --- > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > Attachments: broker.xml > > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-5016) Memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-5016. Resolution: Cannot Reproduce > Memory not getting released > --- > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > Attachments: broker.xml > > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4928) SendAcknowledgementHandler not getting called
[
https://issues.apache.org/jira/browse/ARTEMIS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879698#comment-17879698
]
Clebert Suconic commented on ARTEMIS-4928:
--
the idea is that the OperationContext from the Session gets installed at the
ThreadLocal from the Session whenever the session object is being used.
There are places where we set the storage, and we clear at the end for the
previous storage.
There could be some places where we don't clear... which could be an issue in
an embedded situation where the ThreadPool is shared between the two servers.
If you use two servers in VM you should at least make sure each server uses its
own ExecutorFactory to not have the threads shared. or we (with your help)
could do some cleanup to make sure we reset it at the end.
> SendAcknowledgementHandler not getting called
> -
>
> Key: ARTEMIS-4928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.32.0, 2.35.0, 2.36.0
> Environment: The environment is Linux based, with Azul Java 17. I
> can update with more precise details if needed.
> Artemis version is 2.32.0. However, Artemis broker and the application (and
> thus client producer) are in the same JVM with socket transports.
> We do not see any exceptions in our logs.
>
>Reporter: Rick Parker
>Priority: Critical
> Attachments: image-2024-07-17-13-41-55-900.png,
> image-2024-07-17-13-49-53-962.png, image-2024-08-12-17-44-03-698.png,
> image-2024-08-12-17-45-55-812.png, image-2024-08-12-18-36-35-508.png,
> image-2024-08-12-18-37-10-723.png, image-2024-08-12-18-37-44-279.png,
> image-2024-09-04-15-09-31-595.png, image-2024-09-04-15-10-04-610.png
>
>
> We have been using ArtemisMQ since 2016, and recently upgrading from 2.19.1
> on JDK8 to 2.32.0 on JDK17. We occasionally experience what looks like a
> failure to acknowledge the sending of a message by a (CORE) producer, since
> doing that upgrade, and it brings our application to a halt.
> When I say occasionally, we have a nightly performance test of our
> application that sends about 20-30 million messages from the one producer.
> This failure to acknowledge the send so far has happened twice in the space
> of about a month, which means it is happening approximately every 250-400
> million messages or perhaps more. This also means we don't currently have a
> self contained reproduction of the problem. We are starting to think about
> how we might reproduce it more frequently, if possible, since we have now
> seen it twice and have gained a tiny bit more understanding.
> The symptom is a failure to be called back from the send, and inspecting a
> heap dump I _think_ confirms that the producer is sitting on a send - but I
> am not an expert on the internal workings of Artemis and many apologies in
> advance if I either mislead or point fingers inappropriately.
> We will try upgrading to the latest 2.35.0 (as at time of writing) to see if
> it goes away - the fixed issues don't immediately shout out that it might be
> solved however.
> The API from which we do not get called back is:
> {{org.apache.activemq.artemis.api.core.client.ClientProducer.}}
> {{send(SimpleString address, Message message, SendAcknowledgementHandler
> handler)}}
> Can a misbehaving handler/callback somehow cause this? e.g. what happens if
> it throws an exception? (which we are not seeing bubble up anywhere, but
> haven not ruled it out)
> I have a screenshot of what looks like an interesting part of the heap dump -
> the {{{}ChannelImpl{}}}. To my eyes the {{firstStoredCommandID}} value looks
> out of sync with the content ({{{}correlationID{}}} of message) of the
> {{resendCache}} which is lagging behind for some reason. 8,815,497 is the
> message that has not had the handler called. But like I say, I'm looking at
> all this for the first time with little understanding.
> !image-2024-07-17-13-41-55-900.png!
> It also looks like the same message is still present in the broker data
> structures / heap dump, along with 8,815,495
> !image-2024-07-17-13-49-53-962.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5035) Use randomProtocol in certain tests
Clebert Suconic created ARTEMIS-5035:
Summary: Use randomProtocol in certain tests
Key: ARTEMIS-5035
URL: https://issues.apache.org/jira/browse/ARTEMIS-5035
Project: ActiveMQ Artemis
Issue Type: Test
Reporter: Clebert Suconic
For some tests it's not strictly required to run the test on every protocol.
They should not make a difference in semantic and it takes out precious time
out of the CIs.
To still run the tests we should make a random choice instead of keeping 3 test
methods.
with the following pattern:
@Test
testRandomProtocl() {
doTest(randomProtocol());
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5001) Relax consistency requirement on OperationContext for Mirror send operations.
[ https://issues.apache.org/jira/browse/ARTEMIS-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-5001: - Summary: Relax consistency requirement on OperationContext for Mirror send operations. (was: Improve OperationContextImpl API to take ConsistencyLevel instead of a boolean true | false) > Relax consistency requirement on OperationContext for Mirror send operations. > - > > Key: ARTEMIS-5001 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5001 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.37.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 7h > Remaining Estimate: 0h > > When I worked on AMQP Mirror I did not actually envision being used with > journal replication. I actually thought more about adding multiple mirrored > options instead. > However an user reported me that when using mirror and journal replication > combined, the sends could take a lot longer to happen (some normal latency) > and the acks would eventually be missed. > I should add an option to ignore the replication for the Mirror Target. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-5001) Improve OperationContextImpl API to take ConsistencyLevel instead of a boolean true | false
[ https://issues.apache.org/jira/browse/ARTEMIS-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-5001: - Summary: Improve OperationContextImpl API to take ConsistencyLevel instead of a boolean true | false (was: Add configuration option to relax syncs journal replication for Mirror Target) > Improve OperationContextImpl API to take ConsistencyLevel instead of a > boolean true | false > --- > > Key: ARTEMIS-5001 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5001 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.37.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > Time Spent: 5h 40m > Remaining Estimate: 0h > > When I worked on AMQP Mirror I did not actually envision being used with > journal replication. I actually thought more about adding multiple mirrored > options instead. > However an user reported me that when using mirror and journal replication > combined, the sends could take a lot longer to happen (some normal latency) > and the acks would eventually be missed. > I should add an option to ignore the replication for the Mirror Target. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-4971) AckManager "giving up" processing of Acks in warning log level
[
https://issues.apache.org/jira/browse/ARTEMIS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic resolved ARTEMIS-4971.
--
Fix Version/s: 2.38.0
Resolution: Fixed
> AckManager "giving up" processing of Acks in warning log level
> --
>
> Key: ARTEMIS-4971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Minor
> Fix For: 2.38.0
>
>
> Within the AMQP AckManager, the following log message, currently at DEBUG
> level, should be increased to WARN level:
> {code:java}
> logger.debug("Retried {} {} times, giving up on the entry now", retry,
> retry.getPageAttempts());{code}
> Setting this log to WARN level would allow operators to be aware of two
> things:
> - The AckManager may require configuration tuning of queue/page attempts.
> This can easily occur with the default configuration when handling large
> messages.
> - Missed message replication, which is crucial when replication is required,
> allowing operators to investigate the source of the problem.
> The downside is that this change may trigger a large number of logs when
> enabled on Artemis nodes containing messages created before the mirroring
> configuration activation.
> This might not be desirable for everyone, so it could be beneficial to have
> it enabled as an optional parameter, configurable via a system environment
> variable, similar to the fine-tuning options available for AckManager.
> Ideally, the log should as well contain the queue name, which would allow to
> track down the source of messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4971) AckManager "giving up" processing of Acks in warning log level
[
https://issues.apache.org/jira/browse/ARTEMIS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877486#comment-17877486
]
Clebert Suconic commented on ARTEMIS-4971:
--
As part of ARTEMIS-5010 I am now doing a flush on the MirrorTarget. Which means
you don't need to tune the retries any more. (hopefully).
I'm closing this as a related to ARTEMIS-5010 as that will address this issue.
> AckManager "giving up" processing of Acks in warning log level
> --
>
> Key: ARTEMIS-4971
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4971
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.35.0, 2.36.0
>Reporter: Jean-Pascal Briquet
>Priority: Minor
>
> Within the AMQP AckManager, the following log message, currently at DEBUG
> level, should be increased to WARN level:
> {code:java}
> logger.debug("Retried {} {} times, giving up on the entry now", retry,
> retry.getPageAttempts());{code}
> Setting this log to WARN level would allow operators to be aware of two
> things:
> - The AckManager may require configuration tuning of queue/page attempts.
> This can easily occur with the default configuration when handling large
> messages.
> - Missed message replication, which is crucial when replication is required,
> allowing operators to investigate the source of the problem.
> The downside is that this change may trigger a large number of logs when
> enabled on Artemis nodes containing messages created before the mirroring
> configuration activation.
> This might not be desirable for everyone, so it could be beneficial to have
> it enabled as an optional parameter, configurable via a system environment
> variable, similar to the fine-tuning options available for AckManager.
> Ideally, the log should as well contain the queue name, which would allow to
> track down the source of messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5016) Artemis active MQ memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877140#comment-17877140 ] Clebert Suconic commented on ARTEMIS-5016: -- I will allow this to be open another day. If I don’t get more details I will close this. Thanks. > Artemis active MQ memory not getting released > - > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-5016) Artemis active MQ memory not getting released
[ https://issues.apache.org/jira/browse/ARTEMIS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877138#comment-17877138 ] Clebert Suconic commented on ARTEMIS-5016: -- That is a very vague description. Is it not releasing because you are only sending messages and not consuming them ? Have you configured paging to your work load ? What test are you performing. We do these sort of tests multiple times a day. Without a more detailed description on how you produced this condition will likely end up in a closed or ignored JIRA Please add some context in how he issue happens. > Artemis active MQ memory not getting released > - > > Key: ARTEMIS-5016 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5016 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native >Affects Versions: 2.32.0, 2.35.0 >Reporter: Raghurama laxmikishore vedula >Assignee: Clebert Suconic >Priority: Major > > It seems the Memory usage of artemis active mq cluster is always growing up > but memory is not getting freed even there is no load on the broker due to > this we have to restart container to free the memory else we get OOM issues > and resulted to container restarts. > we are suspecting a memory leak or any configurations that need to adjusted > Config details: > Container memory : 4 GB > CPU : 2000m > JVM Min and Max : 2GB > Additional JVM ops: "-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=300m > -XX:ReservedCodeCacheSize=256m -XX:NewRatio=2 -Xss256k > -XX:MaxDirectMemorySize=200m" -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5010) AckManager records from mirror are not being replicated
Clebert Suconic created ARTEMIS-5010: Summary: AckManager records from mirror are not being replicated Key: ARTEMIS-5010 URL: https://issues.apache.org/jira/browse/ARTEMIS-5010 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.37.0 Reporter: Clebert Suconic Fix For: 2.38.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (ARTEMIS-5003) print a warning if Artemis-profile file does not exist.
[ https://issues.apache.org/jira/browse/ARTEMIS-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic resolved ARTEMIS-5003. -- Resolution: Fixed > print a warning if Artemis-profile file does not exist. > --- > > Key: ARTEMIS-5003 > URL: https://issues.apache.org/jira/browse/ARTEMIS-5003 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.38.0 > > > Say the user did not use artemis upgrade to switch a new version. The new > profile files for utilities may not exist. > The scripting could print a more user friendly message about what happened. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5003) print a warning if Artemis-profile file does not exist.
Clebert Suconic created ARTEMIS-5003: Summary: print a warning if Artemis-profile file does not exist. Key: ARTEMIS-5003 URL: https://issues.apache.org/jira/browse/ARTEMIS-5003 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.38.0 Say the user did not use artemis upgrade to switch a new version. The new profile files for utilities may not exist. The scripting could print a more user friendly message about what happened. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-5001) Add configuration option to relax syncs journal replication for Mirror Target
Clebert Suconic created ARTEMIS-5001: Summary: Add configuration option to relax syncs journal replication for Mirror Target Key: ARTEMIS-5001 URL: https://issues.apache.org/jira/browse/ARTEMIS-5001 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.37.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.38.0 When I worked on AMQP Mirror I did not actually envision being used with journal replication. I actually thought more about adding multiple mirrored options instead. However an user reported me that when using mirror and journal replication combined, the sends could take a lot longer to happen (some normal latency) and the acks would eventually be missed. I should add an option to ignore the replication for the Mirror Target. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4989) Bump slf4j.version from 2.0.13 to 2.0.16
[ https://issues.apache.org/jira/browse/ARTEMIS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4989. > Bump slf4j.version from 2.0.13 to 2.0.16 > > > Key: ARTEMIS-4989 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4989 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4992) Bump org.codehaus.mojo:exec-maven-plugin from 3.3.0 to 3.4.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4992. > Bump org.codehaus.mojo:exec-maven-plugin from 3.3.0 to 3.4.1 > > > Key: ARTEMIS-4992 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4992 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4994) update to Spring 5.3.39
[ https://issues.apache.org/jira/browse/ARTEMIS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4994. > update to Spring 5.3.39 > --- > > Key: ARTEMIS-4994 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4994 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4991) Bump io.micrometer:micrometer-core from 1.13.2 to 1.13.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4991. > Bump io.micrometer:micrometer-core from 1.13.2 to 1.13.3 > > > Key: ARTEMIS-4991 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4991 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4990) Bump selenium.version from 4.23.0 to 4.23.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4990. > Bump selenium.version from 4.23.0 to 4.23.1 > --- > > Key: ARTEMIS-4990 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4990 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4973. > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.37.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4952) JMX countMessages: groupBy not working on AMQP messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4952.
> JMX countMessages: groupBy not working on AMQP messages
> ---
>
> Key: ARTEMIS-4952
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4952
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMX, management
>Affects Versions: 2.35.0
>Reporter: nmeylan
>Priority: Minor
> Fix For: 2.37.0
>
> Attachments: image-2024-07-25-09-54-32-066.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I encountered weird behavior with JMX _countMessages(String, String)_ when
> messages are produced via *AMQP* then moved to another queue and when I call
> *countMessages* operation with a group by
> h2. Context:
> * I create *1600 *messages to *queue.1*, using *CORE* protocol
> * I create *440 *messages to *queue.2*, using *AMQP* protocol
> * I move all messages from *queue.1* to *dl.default* queue, using
> moveMessages operation
> * I move all messages from *queue.2* to *dl.default* queue, using
> moveMessages operation
>
> h2. Current behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"null": 440, "queue.1": 1600}
> {code}
> If I also filter by _ _AMQ_ORIG_QUEUE='queue.2'_ i get
> {code}
> {"null": 440}
> {code}
> !image-2024-07-25-09-54-32-066.png!
>
> h2. Expected behavior
> Calling *countMessages* operation on queue *dl.default* with a groupBy _
> _AMQ_ORIG_QUEUE_ i get:
> {code}
> {"queue.2": 440, "queue.1": 1600}
> {code}
> h2. Notes
> I was wondering why
> [message.getObjectProperty|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/QueueControlImpl.java#L1164]
> is called instead of
> [message.getObjectPropertyForFilter|https://github.com/apache/activemq-artemis/blob/41ec279e2240fd4a84e1c0e7902623682bc5e785/artemis-server/src/main/java/org/apache/activemq/artemis/core/filter/impl/FilterImpl.java#L237]
> as for filtering
> I did the test using getObjectPropertyForFilter instead of getObjectProperty
> and it works
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4954) AddressControl.pause() can pause the snf queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4954. > AddressControl.pause() can pause the snf queue > -- > > Key: ARTEMIS-4954 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4954 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: management >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Configure 2 or more brokers in a load-balancing cluster > (message-load-balancing=ON_DEMAND for cluster connection, > redistributon-delay=0 for catch-all address). > Start consumers (preferably ones with a throttled consume rate) on multiple > addresses on one broker. > Start producers (with a higher production rate than the consumers) on the > opposite broker for the same addresses. > Wait for a little bit of message backlog to occur. > Pause one address on the broker where the producer is / was connected > We see a backlog develop in the SF queue and delivery to the consumer on the > other broker remains blocked, even after all the messages on the consumer > broker are consumed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4960) Ubuntu package name change preventing Docker image build
[
https://issues.apache.org/jira/browse/ARTEMIS-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4960.
> Ubuntu package name change preventing Docker image build
>
>
> Key: ARTEMIS-4960
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4960
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{eclipse-temurin:21-jre}} and {{eclipse-temurin:21-jdk}} Docker tags
> were recently updated to point to {{21-jre-noble}} and {{21-jdk-noble}}
> respectively. In this new version of Ubuntu the {{libaio1}} package was
> renamed to {{libaio1t64}} so the relevant Docker files need to be updated.
> Here's the error I was getting when attempting to build before updating the
> package name:
> {noformat}
> [+] Building 5.0s (11/19)
>
>
> docker-container:eloquent_stonebraker
> => [internal] load build definition from Dockerfile-ubuntu-21-jre
>
>
> 0.0s
> => => transferring dockerfile: 2.04kB
>
>
> 0.0s
> => [linux/arm64 internal] load metadata for
> docker.io/library/eclipse-temurin:21-jre
>
>
> 0.1s
> => [linux/amd64 internal] load metadata for
> docker.io/library/eclipse-temurin:21-jre
>
>
> 0.2s
> => [internal] load .dockerignore
>
>
> 0.0s
> => => transferring context: 2B
>
>
> 0.0s
> => [internal] load build context
>
>
> 0.0s
> => => transferring context: 7.68kB
>
>
> 0.0s
> => [linux/arm64 1/7] FROM
> docker.io/library/eclipse-temurin:21-jre@sha256:33c033fbc177c46ae097fc01575e6a0df665dbecc49d1cff2227b969672697cb
>
> 0.0s
> => => resolve
> docker.io/library/eclipse-temurin:21-jre@sha256:33c033fbc177c46ae097fc01575e6a0df665dbecc49d1cff2227b969672697cb
>
> 0.0s
> => [linux/amd64 1/7] FROM
> docker.io/library/eclipse-temurin:21-jre@sha256:33c033fbc177c46ae097fc01575e6a0df665dbecc49d1cff2227b969672697cb
>
> 0.0s
> => => resolve
> docker.io/library/eclipse-temurin:21-jre@sha256:33c033fbc177c46ae097fc01575e6a0df665dbecc49d1cff2227b969672697cb
>
> 0.0s
> => CACHED [linux/arm64 2/7] WORKDIR /opt
[jira] [Closed] (ARTEMIS-4987) Bump org.easymock:easymock from 5.3.0 to 5.4.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4987. > Bump org.easymock:easymock from 5.3.0 to 5.4.0 > -- > > Key: ARTEMIS-4987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4987 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4809) Make intermediateMessageReferences initial capacity configurable
[
https://issues.apache.org/jira/browse/ARTEMIS-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4809.
Resolution: Fixed
> Make intermediateMessageReferences initial capacity configurable
>
>
> Key: ARTEMIS-4809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4809
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Josh Byster
>Priority: Minor
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> In some setups, there could be a few hundred thousand queues that are created
> due to many consumers that are connecting. However, most of these are empty
> and stay empty for the entire day since there aren't necessarily messages to
> be sent.
> The 8K {{intermediateMessageReferences}} instantiates an 64KB buffer
> ({{Object[]}}). This means we have large allocation and live heap that
> ultimately remains empty for almost the entire day.
> It would be quite nice if we could configure this initial size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4982) AMQP Large message files not removed immediately on failed sends
[ https://issues.apache.org/jira/browse/ARTEMIS-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4982. > AMQP Large message files not removed immediately on failed sends > > > Key: ARTEMIS-4982 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4982 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.36.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.37.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When an incoming large message is rejected for any reason the large message > file is not cleaned up immediately as it should be. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4984) Update to ErrorProne 2.30.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4984. > Update to ErrorProne 2.30.0 > --- > > Key: ARTEMIS-4984 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4984 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.32+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4986. > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.32+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" in 2.32.0 changed a > String that was used on the wire for Voting. That string was sent on the Vote > packet, and so created an incompatibility if mixing a broker <= 2.31.2 with > those of versions 2.32.0 - 2.36.0 (e.g during a rolling upgrade) where they > dont understand each others values. The other nodes would fail with the > following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry with the older packet in case the response wasn't found, before trying > for the full timeout with the current value. > The wire version will be bumped in 2.37.0 such that this process does not > occur against new brokers, which will then be known to understand both values. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4939) Allow configuring request & response header sizes for embedded web server
[
https://issues.apache.org/jira/browse/ARTEMIS-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4939.
> Allow configuring request & response header sizes for embedded web server
> -
>
> Key: ARTEMIS-4939
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4939
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In use-cases with large HTTP headers (e.g. using SSO) Jetty can choke on
> large headers and emit a message like:
> {noformat}
> 2024-07-12 11:41:32,875 WARN [org.eclipse.jetty.http.HttpParser] Header is
> too large 8193>8192{noformat}
> This should be configurable in {{bootstrap.xml}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4985) Message priority occasionally broken
[ https://issues.apache.org/jira/browse/ARTEMIS-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4985. > Message priority occasionally broken > > > Key: ARTEMIS-4985 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4985 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.37.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes a lower priority message may be dispatched before a higher priority > message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4981) update commons-lang3 to 3.16.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4981. > update commons-lang3 to 3.16.0 > -- > > Key: ARTEMIS-4981 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4981 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4979) update asciidoctorj-pdf to 2.3.18
[ https://issues.apache.org/jira/browse/ARTEMIS-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4979. > update asciidoctorj-pdf to 2.3.18 > - > > Key: ARTEMIS-4979 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4979 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4980) adjust build handling of module sources jars
[ https://issues.apache.org/jira/browse/ARTEMIS-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4980. > adjust build handling of module sources jars > > > Key: ARTEMIS-4980 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4980 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > > Currently the sources jars are mostly produced at verify phase, rather than > the usual package phase, which has caused a variety of issues in the past > such as complicating reproducibility checks, and causing the modules doing > shading (at package phase) to download prior snapshots of themselves for > their own sources. They are also always produced, even though they are not > typically used outside release builds. > Adjust the handling of sources jars such that they are all created at the > usual package phase, and are only produced when using the release build > profiles. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4977) update jgroups to 5.3.10
[ https://issues.apache.org/jira/browse/ARTEMIS-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4977. > update jgroups to 5.3.10 > > > Key: ARTEMIS-4977 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4977 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4963) Reject openwire senders that lack SEND permissions on attach
[ https://issues.apache.org/jira/browse/ARTEMIS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4963. > Reject openwire senders that lack SEND permissions on attach > > > Key: ARTEMIS-4963 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4963 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.36.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.37.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently the Openwire producers are allowed to attach even when the named > destination(s) it requests don't offer send permissions to the logged in user > (the sends themselves are validated). The sends from these named or from > anonymous producers are checked for permission but only after such things as > conversion of the message to Core has happened which leads to unnecessary GC > overhead and wasted CPU cycles if the send is going to ultimately be > rejected. > We should reject Openwire senders on attach (which is what the ActiveMQ > 'Classic' broker does) and we should check send permissions prior to > unnecessarily converting messages to Core to reduce overhead from anonymous > senders that are sending into destinations they cannot write to. This change > doesn't introduce any new security but simply would respond more quickly and > efficiently than the current code would. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4955) Support broker properties from JSON files
[ https://issues.apache.org/jira/browse/ARTEMIS-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4955. > Support broker properties from JSON files > - > > Key: ARTEMIS-4955 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4955 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The broker properties are low level, lower level than xml, however it is very > powerful but the current format is too verbose and requires to escape > characters that could be included in the broker properties: ' ', ' > ', '=', ':'. The JSON format is more compact and only requires to escape JSON > reserved characters that are not typically used in the broker properties. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4909) update category names for "Reloading configuration"
[
https://issues.apache.org/jira/browse/ARTEMIS-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4909.
> update category names for "Reloading configuration"
> ---
>
> Key: ARTEMIS-4909
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4909
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 2.35.0
>Reporter: Erwin Dondorp
>Assignee: Erwin Dondorp
>Priority: Minor
> Fix For: 2.37.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When the broker.xml file is reloaded, the following logfile messages are
> produced:
> {noformat}
> 2024-07-07 20:30:08,138 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: security
> 2024-07-07 20:30:08,140 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: address settings
> 2024-07-07 20:30:08,143 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: diverts
> 2024-07-07 20:30:08,150 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: addresses
> [...]
> 2024-07-07 20:30:08,151 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: bridges
> 2024-07-07 20:30:08,151 INFO [org.apache.activemq.artemis.core.server]
> AMQ221056: Reloading configuration: protocol services
> {noformat}
> in would be more consistent when the actual top-level XML tags are mentioned
> here as these are almost the same.
> and it closer matches the documentation, see
> https://activemq.apache.org/components/artemis/documentation/latest/config-reload.html
> proposing:
> * security --> security-settings
> * address settings --> address-settings
> * diverts (already fine)
> * addresses (already fine)
> * bridges (already fine)
> * protocol services --> this part is not documented in
> https://activemq.apache.org/components/artemis/documentation/latest/config-reload.html,
> let's not touch that now.
> a PR is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4976) update to testcontainers 1.20.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4976. > update to testcontainers 1.20.1 > --- > > Key: ARTEMIS-4976 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4976 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.37.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4969) FQQN Security settings not honored when an AMQP Sender attaches
[ https://issues.apache.org/jira/browse/ARTEMIS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4969. > FQQN Security settings not honored when an AMQP Sender attaches > --- > > Key: ARTEMIS-4969 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4969 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.36.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.37.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When an AMQP sender link is attaching with an FQQN in the target address the > initialization code is not checking fully if the sender has specifically > granted FQQN access and can fail the attach in error. Instead of just > checking the FQQN address portion of the target addres both the FQQN address > and queue should be checked with the security store so that the link attach > can complete when authorized. This was addressed for Core clients in > ARTEMIS-4580 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4974) Disable run from the Shell
[ https://issues.apache.org/jira/browse/ARTEMIS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4974. > Disable run from the Shell > -- > > Key: ARTEMIS-4974 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4974 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > With the separation of profiles in the script, we cannot allow run to be > called from the Shell, as that would use wrong variables and log4j > configurations. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4959) moveMessages operation can move more messages than max messageCount
[
https://issues.apache.org/jira/browse/ARTEMIS-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4959.
> moveMessages operation can move more messages than max messageCount
> ---
>
> Key: ARTEMIS-4959
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4959
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: management
>Affects Versions: 2.36.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When paging and many messages in a queue, the following is observed:
> $ bin/artemis producer --user admin --password admin --url
> tcp://localhost:61616 --message-count 1 --message-size 10240
> --destination queue://FOO
> ...
> $ curl -XPOST -H "Content-Type: application/json" -H "Origin:
> http://localhost"; --user "admin:admin" -d
> '{"type":"exec","mbean":"org.apache.activemq.artemis:broker=\"0.0.0.0\",component=addresses,address=\"FOO\",subcomponent=queues,routing-type=\"anycast\",queue=\"FOO\"","operation":"moveMessages(int,java.lang.String,java.lang.String,boolean,int)","arguments":[500,"","DLQ",false,500]}'
> ...
>
> {"request":{"mbean":"org.apache.activemq.artemis:address=\"FOO\",broker=\"0.0.0.0\",component=addresses,queue=\"FOO\",routing-type=\"anycast\",subcomponent=queues","arguments":[500,"","DLQ",false,500],"type":"exec","operation":"moveMessages(int,java.lang.String,java.lang.String,boolean,int)"},"value":8630,"timestamp":1718395680,"status":200}
> Note that the messageCount for the moveMessages operation was 500, but in
> reality 8630 messages were moved (verified with queue stats). This does not
> seem to happen for queues with a low queue depth.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated ARTEMIS-4702:
-
Parent: ARTEMIS-4785
Issue Type: Sub-task (was: Improvement)
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Sub-task
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{{}queue stat{}}}, {{{}consumer{}}},
> {{{}producer{}}}, etc. commands as well. At best, it's overkill to use 8G of
> memory for these secondary commands and at worst it can actually prevent them
> from operating at all (e.g. if the machine is low on memory).
> Add a utility profile for the commands other than 'run' to use for their own
> settings (and logging config, see ARTEMIS-4785)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4785. > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.37.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4702.
Resolution: Fixed
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Sub-task
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{{}queue stat{}}}, {{{}consumer{}}},
> {{{}producer{}}}, etc. commands as well. At best, it's overkill to use 8G of
> memory for these secondary commands and at worst it can actually prevent them
> from operating at all (e.g. if the machine is low on memory).
> Add a utility profile for the commands other than 'run' to use for their own
> settings (and logging config, see ARTEMIS-4785)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Reopened] (ARTEMIS-4702) Add utility profile for CLI commands other than run
[
https://issues.apache.org/jira/browse/ARTEMIS-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic reopened ARTEMIS-4702:
--
> Add utility profile for CLI commands other than run
> ---
>
> Key: ARTEMIS-4702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.37.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Right now every {{artemis}} command uses the same JVM settings from
> {{{}artemis.profile{}}}. So, for example, if the settings included {{-Xms8G
> -Xmx8G}} for running the broker (i.e. the {{run}} command) those same
> settings would be used for the {{{}queue stat{}}}, {{{}consumer{}}},
> {{{}producer{}}}, etc. commands as well. At best, it's overkill to use 8G of
> memory for these secondary commands and at worst it can actually prevent them
> from operating at all (e.g. if the machine is low on memory).
> Add a utility profile for the commands other than 'run' to use for their own
> settings (and logging config, see ARTEMIS-4785)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.33+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-4986: - Summary: Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.33+ (was: Replication/Vote incompatibility between any version prior to 2.32.2 (inclusive) and 2.33+) > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.33+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.31.2 (inclusive) and 2.33+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-4986: - Affects Version/s: 2.32.0 (was: 2.31.0) > Replication/Vote incompatibility between any version prior to 2.31.2 > (inclusive) and 2.33+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.32.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.32.2 (inclusive) and 2.33+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873561#comment-17873561 ] Clebert Suconic commented on ARTEMIS-4986: -- [~robbie] can you close it if you're ok with the title I chose? if not can you come up with something better please? > Replication/Vote incompatibility between any version prior to 2.32.2 > (inclusive) and 2.33+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4986) Replication/Vote incompatibility between any version prior to 2.32.2 (inclusive) and 2.33+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-4986: - Summary: Replication/Vote incompatibility between any version prior to 2.32.2 (inclusive) and 2.33+ (was: Replication/Vote incompatibility between 2.30 and 2.31+) > Replication/Vote incompatibility between any version prior to 2.32.2 > (inclusive) and 2.33+ > -- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4986) Replication/Vote incompatibility between 2.30 and 2.31+
[ https://issues.apache.org/jira/browse/ARTEMIS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4986. Resolution: Fixed > Replication/Vote incompatibility between 2.30 and 2.31+ > --- > > Key: ARTEMIS-4986 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String > that was used on the wire for Voting. That string was sent on the Vote and > the other nodes would fail with the following message: > AMQ224090: This node is not configured for Quorum Voting, all nodes must be > configured for HA > The server will simply not respond the VoteRequest on that case and the > blockCall timeout will fail. > To fix this I'm applying a shorter timeout that will just be ignored and > retry at the older packet in case the response wasn't found. > I was trying to play with Wire versioning but that scenario turned out to be > more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-3260) Already consumed messages are redelivered after server restart (possible Journal corruption)
[
https://issues.apache.org/jira/browse/ARTEMIS-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3260.
Resolution: Cannot Reproduce
provide a reproducer and we may take a look.
I have fixed a few issues along the years on the journal. at the moment I don't
have any material to work on this issue.
> Already consumed messages are redelivered after server restart (possible
> Journal corruption)
>
>
> Key: ARTEMIS-3260
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3260
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.17.0
> Environment: Embedded Apache Artemis 2.17.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Priority: Blocker
> Attachments: ExampleClient.java, PagingStoreImpl.java,
> QueueImpl.java, activemq_artemis.log, broker.xml, broker.zip,
> restart_log_1_no_recovery-2021-04-22_08.46.52.log,
> restart_log_2_recovery-2021-04-22_08.48.49.log
>
>
> After upgrading from Artemis 2.15.0 to 2.17.0 we are experiencing situations
> (non-deterministic but quite regular) where the embedded Apache Artemis
> instance re-delivers messages to a client again after a server restart.
> Those messages were already processed successfully before restart and the web
> console shows a message count of 0 prior to restarting the process.
> It is also important to note once those stuck messages (which seemingly
> appear from out of nowhere) have been reprocessed newly added messages are
> processed just fine - so what we are seeing is the following:
> # At some point in time messages A,B,C were routed to Queue Q and
> successfully consumed
> # Q is empty (web console)
> # perform broker restart
> # client consumes A,B,C from Q again
> # Q is empty (web console)
> # another client sends X,Y,Z to Q
> # client consumes X,Y,Z
> # Q is empty (web console)
> # perform broker restart
> # client consumes A,B,C from Q again!
> This happens again and again on each boker restart up to a point where the
> broker finally manages to recover from this situation by detecting an invalid
> (negative) address size as indicated by the following log output:
> {quote}2021-04-22 21:04:51.897 WARN
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.addSize(PagingStoreImpl.java:753)
> [Thread-1
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@26bb92e2)]
> {quote}
> {quote}[ARTEMIS] AMQ14: Destination incoming.message has an inconsistent
> and negative address size=-3,379.
> {quote}
> {quote}2021-04-22 21:04:51.897 WARN
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.addSize(PagingStoreImpl.java:753)
> [Thread-1
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@26bb92e2)]
> {quote}
> {quote}[ARTEMIS] AMQ14: Destination incoming.message has an inconsistent
> and negative address size=-3,451.
> {quote}
>
> The full log file of such a situation (where the broker managed to recover)
> is attached together with the broker.xml file that we use as a template to
> configure the embedded instance programmatically.
> The broker runs embedded with the client which consumes messages via AMQP
> using the Apache QPID library (JMS2.0 - v0.57.0) - there is only a single
> Thread ever consuming from a queue and we use transactions to explicitly
> commit or rollback received messages with prefetch disabled
> (jms.prefetchPolicy.all=0)
> Further investigation / debugging has shown that when messages are
> redelivered the above log outputs concerning the negative address size are
> absent and the reason is that the value returned by
> messageReference.getMessageMemoryEstimate() is different for the exact same
> message in line 1022 of class
> org.apache.activemq.artemis.core.server.impl.QueueImpl.
> This difference stems from a different value being calculated in
> AMQPStandardMessage class (getMemoryEstimate()) and the difference is equal
> to the value returned by
> unmarshalledApplicationPropertiesMemoryEstimateFromData() so I assume that
> the applicationProperties are sometimes not being considered (I still have to
> verify this).
> I can also provide the complete broker journal for such a situation which we
> currently use for debugging if this helps to analyze the issue (approx. ~25MB
> of files, compressed ~100kB)
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apac
[jira] [Created] (ARTEMIS-4986) Replication/Vote incompatibility between 2.30 and 2.31+
Clebert Suconic created ARTEMIS-4986: Summary: Replication/Vote incompatibility between 2.30 and 2.31+ Key: ARTEMIS-4986 URL: https://issues.apache.org/jira/browse/ARTEMIS-4986 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 2.31.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.37.0 The change for "ARTEMIS-3474 replace non-inclusive terms" changed a String that was used on the wire for Voting. That string was sent on the Vote and the other nodes would fail with the following message: AMQ224090: This node is not configured for Quorum Voting, all nodes must be configured for HA The server will simply not respond the VoteRequest on that case and the blockCall timeout will fail. To fix this I'm applying a shorter timeout that will just be ignored and retry at the older packet in case the response wasn't found. I was trying to play with Wire versioning but that scenario turned out to be more complex. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4928) SendAcknowledgementHandler not getting called
[
https://issues.apache.org/jira/browse/ARTEMIS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873016#comment-17873016
]
Clebert Suconic commented on ARTEMIS-4928:
--
The server definitely plays with OperationContext and completions.
if you are mixing two servers in the same Vm, it's possible that one Thread is
leaking an operationContext from another server, just like it happened on my
case with the Bridge.
If I had a reproducing test with me and was working towards a fix, I would
somehow add System.out around OperationContextImpl.setContext to figure out in
which place I should apply a similar fix I did on ARTEMIS-4821.
For reference, I'm talking about this change:
https://github.com/apache/activemq-artemis/commit/9e8df4cf7a9dc846a01dccac5e661efe229a0057
> SendAcknowledgementHandler not getting called
> -
>
> Key: ARTEMIS-4928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.32.0
> Environment: The environment is Linux based, with Azul Java 17. I
> can update with more precise details if needed.
> Artemis version is 2.32.0. However, Artemis broker and the application (and
> thus client producer) are in the same JVM with socket transports.
> We do not see any exceptions in our logs.
>
>Reporter: Rick Parker
>Priority: Critical
> Attachments: image-2024-07-17-13-41-55-900.png,
> image-2024-07-17-13-49-53-962.png, image-2024-08-12-17-44-03-698.png,
> image-2024-08-12-17-45-55-812.png, image-2024-08-12-18-36-35-508.png,
> image-2024-08-12-18-37-10-723.png, image-2024-08-12-18-37-44-279.png
>
>
> We have been using ArtemisMQ since 2016, and recently upgrading from 2.19.1
> on JDK8 to 2.32.0 on JDK17. We occasionally experience what looks like a
> failure to acknowledge the sending of a message by a (CORE) producer, since
> doing that upgrade, and it brings our application to a halt.
> When I say occasionally, we have a nightly performance test of our
> application that sends about 20-30 million messages from the one producer.
> This failure to acknowledge the send so far has happened twice in the space
> of about a month, which means it is happening approximately every 250-400
> million messages or perhaps more. This also means we don't currently have a
> self contained reproduction of the problem. We are starting to think about
> how we might reproduce it more frequently, if possible, since we have now
> seen it twice and have gained a tiny bit more understanding.
> The symptom is a failure to be called back from the send, and inspecting a
> heap dump I _think_ confirms that the producer is sitting on a send - but I
> am not an expert on the internal workings of Artemis and many apologies in
> advance if I either mislead or point fingers inappropriately.
> We will try upgrading to the latest 2.35.0 (as at time of writing) to see if
> it goes away - the fixed issues don't immediately shout out that it might be
> solved however.
> The API from which we do not get called back is:
> {{org.apache.activemq.artemis.api.core.client.ClientProducer.}}
> {{send(SimpleString address, Message message, SendAcknowledgementHandler
> handler)}}
> Can a misbehaving handler/callback somehow cause this? e.g. what happens if
> it throws an exception? (which we are not seeing bubble up anywhere, but
> haven not ruled it out)
> I have a screenshot of what looks like an interesting part of the heap dump -
> the {{{}ChannelImpl{}}}. To my eyes the {{firstStoredCommandID}} value looks
> out of sync with the content ({{{}correlationID{}}} of message) of the
> {{resendCache}} which is lagging behind for some reason. 8,815,497 is the
> message that has not had the handler called. But like I say, I'm looking at
> all this for the first time with little understanding.
> !image-2024-07-17-13-41-55-900.png!
> It also looks like the same message is still present in the broker data
> structures / heap dump, along with 8,815,495
> !image-2024-07-17-13-49-53-962.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4928) SendAcknowledgementHandler not getting called
[
https://issues.apache.org/jira/browse/ARTEMIS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873000#comment-17873000
]
Clebert Suconic commented on ARTEMIS-4928:
--
can you reproduce this with a non embedded scenario?
Can you package your test in a simpler way that somebody else could run it? it
would be great if it was a Unit Test.
> SendAcknowledgementHandler not getting called
> -
>
> Key: ARTEMIS-4928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.32.0
> Environment: The environment is Linux based, with Azul Java 17. I
> can update with more precise details if needed.
> Artemis version is 2.32.0. However, Artemis broker and the application (and
> thus client producer) are in the same JVM with socket transports.
> We do not see any exceptions in our logs.
>
>Reporter: Rick Parker
>Priority: Critical
> Attachments: image-2024-07-17-13-41-55-900.png,
> image-2024-07-17-13-49-53-962.png, image-2024-08-12-17-44-03-698.png,
> image-2024-08-12-17-45-55-812.png
>
>
> We have been using ArtemisMQ since 2016, and recently upgrading from 2.19.1
> on JDK8 to 2.32.0 on JDK17. We occasionally experience what looks like a
> failure to acknowledge the sending of a message by a (CORE) producer, since
> doing that upgrade, and it brings our application to a halt.
> When I say occasionally, we have a nightly performance test of our
> application that sends about 20-30 million messages from the one producer.
> This failure to acknowledge the send so far has happened twice in the space
> of about a month, which means it is happening approximately every 250-400
> million messages or perhaps more. This also means we don't currently have a
> self contained reproduction of the problem. We are starting to think about
> how we might reproduce it more frequently, if possible, since we have now
> seen it twice and have gained a tiny bit more understanding.
> The symptom is a failure to be called back from the send, and inspecting a
> heap dump I _think_ confirms that the producer is sitting on a send - but I
> am not an expert on the internal workings of Artemis and many apologies in
> advance if I either mislead or point fingers inappropriately.
> We will try upgrading to the latest 2.35.0 (as at time of writing) to see if
> it goes away - the fixed issues don't immediately shout out that it might be
> solved however.
> The API from which we do not get called back is:
> {{org.apache.activemq.artemis.api.core.client.ClientProducer.}}
> {{send(SimpleString address, Message message, SendAcknowledgementHandler
> handler)}}
> Can a misbehaving handler/callback somehow cause this? e.g. what happens if
> it throws an exception? (which we are not seeing bubble up anywhere, but
> haven not ruled it out)
> I have a screenshot of what looks like an interesting part of the heap dump -
> the {{{}ChannelImpl{}}}. To my eyes the {{firstStoredCommandID}} value looks
> out of sync with the content ({{{}correlationID{}}} of message) of the
> {{resendCache}} which is lagging behind for some reason. 8,815,497 is the
> message that has not had the handler called. But like I say, I'm looking at
> all this for the first time with little understanding.
> !image-2024-07-17-13-41-55-900.png!
> It also looks like the same message is still present in the broker data
> structures / heap dump, along with 8,815,495
> !image-2024-07-17-13-49-53-962.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871451#comment-17871451 ] Clebert Suconic commented on ARTEMIS-4785: -- [~brusdev] I made ARTEMIS-4785 a sub task of this JIRA. note to self / us: Lets make sure we mention that Run is not available any more on Shell on the release notes (versions.adoc). I was going to add a note now but it felt weird adding the note without ARTEMIS-4785 completed first. > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4974) Disable run from the Shell
[ https://issues.apache.org/jira/browse/ARTEMIS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-4974: - Parent: ARTEMIS-4785 Issue Type: Sub-task (was: Improvement) > Disable run from the Shell > -- > > Key: ARTEMIS-4974 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4974 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.37.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > With the separation of profiles in the script, we cannot allow run to be > called from the Shell, as that would use wrong variables and log4j > configurations. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871158#comment-17871158 ] Clebert Suconic commented on ARTEMIS-4973: -- Ohhh... sorry.. you're talking about pageLimitBytes.. I thought you were referring to max-size-messages and max-size-bytes. > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4973) pageSizeBytes/pageLimitBytes combination can cause Address full
[ https://issues.apache.org/jira/browse/ARTEMIS-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871157#comment-17871157 ] Clebert Suconic commented on ARTEMIS-4973: -- It is actually valid to set page-limit very low to start paging right away. for paging Policy==FAIL, page-size-bytes should to be used at all in the calculation. there are actually lots of tests that would fail if you change this semantic, and a lot of users would have their applications broken. > pageSizeBytes/pageLimitBytes combination can cause Address full > --- > > Key: ARTEMIS-4973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.36.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is an edge case where adjusting pageSizeBytes can cause "Address is > full" errors, even though the address is not full. > Do we need to enforce that pageSizeBytes <= pageLimitBytes? > Reproducer steps: > Step 1: configure pageSizeBytes == pageLimitBytes == 1mb: > $ cat my.broker.properties > addressSettings."FOO".pageSizeBytes=1048576 > addressSettings."FOO".pageLimitBytes=1048576 > addressSettings."FOO".maxSizeBytes=1048576 > addressSettings."FOO".pageFullMessagePolicy=FAIL > addressConfigurations."FOO".routingTypes=MULTICAST > addressConfigurations."FOO".queueConfigs."FOO".name=FOO > addressConfigurations."FOO".queueConfigs."FOO".address=FOO > addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST > Step 2: run broker > bin/artemis run --properties my.broker.properties > Step 3: produce 15 messages > $ bin/artemis producer --user admin --password admin --destination > topic://FOO --message-count 15 --message-size 10 --protocol amqp > Step 4: observe paging started on the destination (but the page size is > 328kb, can hold more messages) > INFO [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on > address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 > messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 > bytes (-1 messages); > Step 5: stop broker, increase page size > cat my.broker.properties > addressSettings."FOO".pageSizeBytes=4048576 > ... > Step 6: run broker, observe logs show paging warning > 2024-06-25 15:23:47,135 WARN [org.apache.activemq.artemis.core.server] > AMQ224123: Address FOO has more pages than allowed. System currently has 1 > pages, while the estimated max number of pages is 0 based on the > page-limit-bytes (1048576) / page-size (4048576) > Step 7: try to produce a message, address full > WARN [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] > AMQ229102: Address "FOO" is full. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4974) Disable run from the Shell
Clebert Suconic created ARTEMIS-4974: Summary: Disable run from the Shell Key: ARTEMIS-4974 URL: https://issues.apache.org/jira/browse/ARTEMIS-4974 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.37.0 With the separation of profiles in the script, we cannot allow run to be called from the Shell, as that would use wrong variables and log4j configurations. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4964) Add FAST ACK tests with OpenWire, AMQP and OpenWire
Clebert Suconic created ARTEMIS-4964: Summary: Add FAST ACK tests with OpenWire, AMQP and OpenWire Key: ARTEMIS-4964 URL: https://issues.apache.org/jira/browse/ARTEMIS-4964 Project: ActiveMQ Artemis Issue Type: Test Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.37.0 I should add a test where I'm validating the delayed storage of a message versus acks coming from the mirror and their retries -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4928) SendAcknowledgementHandler not getting called
[
https://issues.apache.org/jira/browse/ARTEMIS-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869986#comment-17869986
]
Clebert Suconic commented on ARTEMIS-4928:
--
Not necessarily related to the SendACk, but since the Bridge is using the
SendACK I recently had the following fix in 2.36.0:
ARTEMIS-4821
if your sendACK is somehow related to the Bridge, this might be related ^
> SendAcknowledgementHandler not getting called
> -
>
> Key: ARTEMIS-4928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.32.0
> Environment: The environment is Linux based, with Azul Java 17. I
> can update with more precise details if needed.
> Artemis version is 2.32.0. However, Artemis broker and the application (and
> thus client producer) are in the same JVM with socket transports.
> We do not see any exceptions in our logs.
>
>Reporter: Rick Parker
>Priority: Critical
> Attachments: image-2024-07-17-13-41-55-900.png,
> image-2024-07-17-13-49-53-962.png
>
>
> We have been using ArtemisMQ since 2016, and recently upgrading from 2.19.1
> on JDK8 to 2.32.0 on JDK17. We occasionally experience what looks like a
> failure to acknowledge the sending of a message by a (CORE) producer, since
> doing that upgrade, and it brings our application to a halt.
> When I say occasionally, we have a nightly performance test of our
> application that sends about 20-30 million messages from the one producer.
> This failure to acknowledge the send so far has happened twice in the space
> of about a month, which means it is happening approximately every 250-400
> million messages or perhaps more. This also means we don't currently have a
> self contained reproduction of the problem. We are starting to think about
> how we might reproduce it more frequently, if possible, since we have now
> seen it twice and have gained a tiny bit more understanding.
> The symptom is a failure to be called back from the send, and inspecting a
> heap dump I _think_ confirms that the producer is sitting on a send - but I
> am not an expert on the internal workings of Artemis and many apologies in
> advance if I either mislead or point fingers inappropriately.
> We will try upgrading to the latest 2.35.0 (as at time of writing) to see if
> it goes away - the fixed issues don't immediately shout out that it might be
> solved however.
> The API from which we do not get called back is:
> {{org.apache.activemq.artemis.api.core.client.ClientProducer.}}
> {{send(SimpleString address, Message message, SendAcknowledgementHandler
> handler)}}
> Can a misbehaving handler/callback somehow cause this? e.g. what happens if
> it throws an exception? (which we are not seeing bubble up anywhere, but
> haven not ruled it out)
> I have a screenshot of what looks like an interesting part of the heap dump -
> the {{{}ChannelImpl{}}}. To my eyes the {{firstStoredCommandID}} value looks
> out of sync with the content ({{{}correlationID{}}} of message) of the
> {{resendCache}} which is lagging behind for some reason. 8,815,497 is the
> message that has not had the handler called. But like I say, I'm looking at
> all this for the first time with little understanding.
> !image-2024-07-17-13-41-55-900.png!
> It also looks like the same message is still present in the broker data
> structures / heap dump, along with 8,815,495
> !image-2024-07-17-13-49-53-962.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4859) Bump org.jboss.marshalling:jboss-marshalling-river from 2.0.9.Final to 2.1.4.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4859. > Bump org.jboss.marshalling:jboss-marshalling-river from 2.0.9.Final to > 2.1.4.Final > -- > > Key: ARTEMIS-4859 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4859 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4848) Bump org.codehaus.mojo:javacc-maven-plugin from 2.6 to 3.1.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4848. > Bump org.codehaus.mojo:javacc-maven-plugin from 2.6 to 3.1.0 > > > Key: ARTEMIS-4848 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4848 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4901) Bump owasp.version from 9.2.0 to 10.0.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4901. > Bump owasp.version from 9.2.0 to 10.0.0 > --- > > Key: ARTEMIS-4901 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4901 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4841) Bump jetty.version from 10.0.20 to 10.0.22
[ https://issues.apache.org/jira/browse/ARTEMIS-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4841. > Bump jetty.version from 10.0.20 to 10.0.22 > -- > > Key: ARTEMIS-4841 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4841 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4938) Update commons-lang to 3.15.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4938. > Update commons-lang to 3.15.0 > - > > Key: ARTEMIS-4938 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4938 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Trivial > Fix For: 2.36.0 > > > Update commons-lang to 3.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4936) Verify response correlationId in Core client
[
https://issues.apache.org/jira/browse/ARTEMIS-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4936.
> Verify response correlationId in Core client
>
>
> Key: ARTEMIS-4936
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4936
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Consider a Core client sending packets with blocking semantics and a
> confirmationWindowSize >= 0. For example, consider such a client sending
> multiple durable messages in a transaction and then committing that
> transaction. If, for whatever reason, the response for the commit packet is
> never returned it's possible that the call to commit will _still_ succeed.
> This is because {{ChannelImple}} does not verify the correlation ID set on
> the commit packet and will interpret a _previous_ response as the current
> response to the commit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4855) Bump org.asciidoctor:asciidoctor-maven-plugin from 2.2.4 to 3.0.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4855. > Bump org.asciidoctor:asciidoctor-maven-plugin from 2.2.4 to 3.0.0 > - > > Key: ARTEMIS-4855 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4855 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4940) update to protonj2 test driver 1.0.0-M21
[ https://issues.apache.org/jira/browse/ARTEMIS-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4940. > update to protonj2 test driver 1.0.0-M21 > > > Key: ARTEMIS-4940 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4940 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4882) Bump org.apache.qpid:qpid-jms-client from 1.10.0 to 1.11.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4882. > Bump org.apache.qpid:qpid-jms-client from 1.10.0 to 1.11.0 > -- > > Key: ARTEMIS-4882 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4882 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4908) Update to commons-logging 1.3.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4908. > Update to commons-logging 1.3.3 > --- > > Key: ARTEMIS-4908 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4908 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.36.0 > > > Update to commons-logging 1.3.3 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4887) Bump org.apache.hadoop:hadoop-minikdc from 3.3.1 to 3.4.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4887. > Bump org.apache.hadoop:hadoop-minikdc from 3.3.1 to 3.4.0 > - > > Key: ARTEMIS-4887 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4887 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4840) Bump org.apache.commons:commons-dbcp2 from 2.11.0 to 2.12.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4840. > Bump org.apache.commons:commons-dbcp2 from 2.11.0 to 2.12.0 > --- > > Key: ARTEMIS-4840 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4840 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4838) Bump version.batavia from 1.0.10.Final to 1.0.15.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4838. > Bump version.batavia from 1.0.10.Final to 1.0.15.Final > -- > > Key: ARTEMIS-4838 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4838 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4893) Bump org.codehaus.mojo:build-helper-maven-plugin from 1.8 to 3.6.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4893. > Bump org.codehaus.mojo:build-helper-maven-plugin from 1.8 to 3.6.0 > -- > > Key: ARTEMIS-4893 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4893 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4794) CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge is paused while messages being produced to target node.
[
https://issues.apache.org/jira/browse/ARTEMIS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4794.
> CoreBridge: Duplicate message when bridge is stopped/Lost message when bridge
> is paused while messages being produced to target node.
> -
>
> Key: ARTEMIS-4794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4794
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0, 2.34.0, 2.35.0
>Reporter: nmeylan
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Attachments: BridgeARTEMIS4794Test.java,
> message-not-deliverable.log.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> +Attached test *BridgeDuplicateMessagesARTEMIS4794Test.java*+ highlights the
> issue with _org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl_
> Place it under
> _tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/cluster/bridge_
> {*}Summary{*}:
> When a bridge is stopped while messages being produced to the target
> node, it can lead to duplicate messages.
> {*}Description{*}:
> When Using bridge and programmatically *stopping* it while messages are
> being produced to the target node, the source node fails to get the
> acknowledgement from target node and messages now exists on the source and
> the target node.
> It appears that the "active" flag being set to false when
> BridgeImpl.StopRunnable is called prevent message to be acknowledged by
> _BridgeImpl::sendAcknowledged_ function
>
> {*}Context{*}:
> This bug appear in my code (a custom plugin) because is start and stop Bridge
> programmatically to move messages from one node to another when some
> conditions are met, if they are no longer met I want to stop the moving of
> messages.
>
> *Notes:*
> * Changing bridge configuration
> {_}useDuplicateDetection{_},{_}confirmationWindowSize{_} or
> _producerWindowSize_ parameter do not help to mitigate the issue
> * Not related to large messages, i use large messages in my test to ease
> reproduction
> * Reproduced on 2.30 and 2.34
> * Calling pause() does not create duplicate
> {_}server.getClusterManager().getBridges().get(bridgeName).pause(){_};
>
>
>
> *UPDATE:* When using pause instead of stop in above scenari, I get message
> not being develirable anymore
> {*}Summary{*}:
> When a bridge is paused while *large* messages being produced to the target
> node, it can lead to message not able to be delivered to new consumers.
> {*}Description{*}:
> When Using bridge and programmatically pausing it while messages are being
> produced to the target node, If large messages are being delivered, the
> thread In _BridgeImpl::deliverLargeMessage_ is not awaited, and the bridge is
> paused then the Runnable of deliverLargeMessage is being run, leading to a
> situation were the message won't be delivered to new consumers
> {*}Notes{*}:
> * PauseRunnable does not await for task in {{executor}} to complete,
> deliverLargeMessage do create task in executor
> *
> ** We can see that even after PauseRunnable has complete,
> deliverLargeMessage's task is running after.
> * If I call {{bridge1.onCreditsFlow(true, null);}} to set the flag
> {{blockedOnFlowControl}} to true, before calling pause, it prevent putting
> new task on executor and mitigate the issue, but It feels weird and I think
> there might still be race condition
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4919) AMQP protocol level errors not handled cleanly
[ https://issues.apache.org/jira/browse/ARTEMIS-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4919. > AMQP protocol level errors not handled cleanly > -- > > Key: ARTEMIS-4919 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4919 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.35.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 2.36.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When a remote client violates some AMQP protocol level requirements the > proton AMQP transport can throw and this is not handled correctly an the > transport error event is also not handled which leads to issues if you try > and handle the exception from the transport by triggering a transport level > error event. > Not handling these errors can cause missed transport flushes and or missed > cleanup of connection level resources in some cases. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4831) consistently use surefire default behaviour around test failure
[
https://issues.apache.org/jira/browse/ARTEMIS-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4831.
> consistently use surefire default behaviour around test failure
> ---
>
> Key: ARTEMIS-4831
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4831
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Tests
>Affects Versions: 2.35.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, the artemis build explicitly configures maven/surefire to ignore
> test failures most of the time, both out of the box, and when running most of
> the test profiles. The artemis build _only_ configures maven/surefire to its
> usual standard behaviour (to fail the whole build at the module which first
> failed a test) for the 'fast-tests' profile used in the PR test runs.
> This is horrible out of the box behaviour because if people dont know this,
> as many wont and almost noone would assume, then they can entirely miss the
> fact that there were test failures because they are buried by subsequent test
> output, and the end command result is then success with a nice banner from
> Maven indicating BUILD SUCCESS. Most folks not using something like Jenkins
> with the JUnit test results processing, or running the aggregate surefire
> report after testing and looking, is likely to miss failures they have
> introduced. I have seen this happen in a few PRs just recently.
> Surefire already has a dedicated property to give this behaviour, easily
> configurable via the pom or CLI: {_}maven.test.failure.ignore{_}. The default
> artemis build behaviour should adopt the default surefire behaviour everyone
> is already used to and almost certainly expects it already uses. Anyone who
> does specifically wish to have the ignoring behaviour to run all modules can
> configure maven/surefire when running it, e.g:
> {code:java}
> mvn test -Dmaven.test.failure.ignore{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4866) Bump com.google.cloud.tools:jib-maven-plugin from 3.3.2 to 3.4.3
[ https://issues.apache.org/jira/browse/ARTEMIS-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4866. > Bump com.google.cloud.tools:jib-maven-plugin from 3.3.2 to 3.4.3 > > > Key: ARTEMIS-4866 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4866 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4921) Include protocol name in disconnection log message
[
https://issues.apache.org/jira/browse/ARTEMIS-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-4921.
> Include protocol name in disconnection log message
> --
>
> Key: ARTEMIS-4921
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4921
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.36.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to know the protocol in use when the broker logs a message
> like:
> {noformat}
> WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure
> to 127.0.0.1:48558 has been detected: null [code=GENERIC_EXCEPTION]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4870) Bump com.puppycrawl.tools:checkstyle from 10.16.0 to 10.17.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4870. > Bump com.puppycrawl.tools:checkstyle from 10.16.0 to 10.17.0 > > > Key: ARTEMIS-4870 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4870 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4871) Bump org.osgi:osgi.cmpn from 6.0.0 to 7.0.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4871. > Bump org.osgi:osgi.cmpn from 6.0.0 to 7.0.0 > --- > > Key: ARTEMIS-4871 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4871 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4822) improve build reproducibility
[ https://issues.apache.org/jira/browse/ARTEMIS-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4822. > improve build reproducibility > - > > Key: ARTEMIS-4822 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4822 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.36.0 > > > The artemis-website modules output is not currently reproducible, even though > all the HTML output in it is, because the PDF of the user manual now also > added contains an embedded creation timestamp. > The artemis-commons module pom is a dependency-reduced-pom created by the > shade plugin. It can vary with maven version used during the build, and > whether the release profile is active or not. We can improve the former by > requiring the newer maven versions are used during release. We could > investigate if the latter could be improved by adjusting the pom slightly to > alter the varying bits (around the javadoc plugin) such that they dont. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4894) Bump com.google.guava:guava from 33.0.0-jre to 33.2.1-jre
[ https://issues.apache.org/jira/browse/ARTEMIS-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4894. > Bump com.google.guava:guava from 33.0.0-jre to 33.2.1-jre > - > > Key: ARTEMIS-4894 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4894 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4885) Bump version.jaxb.runtime from 2.3.3 to 2.3.9
[ https://issues.apache.org/jira/browse/ARTEMIS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4885. > Bump version.jaxb.runtime from 2.3.3 to 2.3.9 > - > > Key: ARTEMIS-4885 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4885 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4930) Refactor storage manager tests
[ https://issues.apache.org/jira/browse/ARTEMIS-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4930. > Refactor storage manager tests > -- > > Key: ARTEMIS-4930 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4930 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (ARTEMIS-4897) Bump org.apache.servicemix.tooling:depends-maven-plugin from 1.2 to 1.5.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4897. > Bump org.apache.servicemix.tooling:depends-maven-plugin from 1.2 to 1.5.0 > - > > Key: ARTEMIS-4897 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4897 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.36.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
