[jira] [Work logged] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?focusedWorklogId=919624=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919624 ] ASF GitHub Bot logged work on ARTEMIS-4774: --- Author: ASF GitHub Bot Created on: 16/May/24 03:28 Start Date: 16/May/24 03:28 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4937: URL: https://github.com/apache/activemq-artemis/pull/4937 (no comment) Issue Time Tracking --- Worklog Id: (was: 919624) Remaining Estimate: 0h Time Spent: 10m > PageCounters get out of sync after AckManager > - > > Key: ARTEMIS-4774 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4774 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4774) PageCounters get out of sync after AckManager
[ https://issues.apache.org/jira/browse/ARTEMIS-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846792#comment-17846792 ] Clebert Suconic commented on ARTEMIS-4774: -- The AckManager is leaving the PageCounters out of sync. The issue is that the counters were using delivered counts from paging in the calculation, however the Ackmanager is not actually fetching data in certain retries. To fix this I'm splitting some of the metrics between Paged and NonPaged counters, and removing the need to discount deliveries. also there's some hardening on AckManager and Mirror while fixing this issue > PageCounters get out of sync after AckManager > - > > Key: ARTEMIS-4774 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4774 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4774) PageCounters get out of sync after AckManager
Clebert Suconic created ARTEMIS-4774: Summary: PageCounters get out of sync after AckManager Key: ARTEMIS-4774 URL: https://issues.apache.org/jira/browse/ARTEMIS-4774 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.34.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4773) Performance improvement on page.sync
Clebert Suconic created ARTEMIS-4773: Summary: Performance improvement on page.sync Key: ARTEMIS-4773 URL: https://issues.apache.org/jira/browse/ARTEMIS-4773 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Clebert Suconic PagingStoreImpl::ioSync is holding a readWriteLock while calling sync: https://github.com/apache/activemq-artemis/blob/c523458a9aa4f67ad0e9bdbc5c4733bc88bf55f6/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L516-L529 However that's causing a contention on adding new data: at jdk.internal.misc.Unsafe.park(java.base@17.0.11/Native Method) - parking to wait for <0x8087a170> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(java.base@17.0.11/LockSupport.java:211) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11/AbstractQueuedSynchronizer.java:715) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11/AbstractQueuedSynchronizer.java:938) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@17.0.11/ReentrantReadWriteLock.java:959) at org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.writePage(PagingStoreImpl.java:1249) at org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.page(PagingStoreImpl.java:1242) at org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.page(PagingStoreImpl.java:1173) at org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.addToPage(AbstractJournalStorageManager.java:2256 To fix that I'm going to remove the sync from the readWriteLock. and Ignore an alreadyClosedException. I tested this, and also an user and the improvement was significant, especially with a slower device (that's actually more common on cloud providers these days). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919612=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919612
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:21
Start Date: 15/May/24 23:21
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602361845
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
I don't want to introduce any performance issue. I would prefer going safe.
Issue Time Tracking
---
Worklog Id: (was: 919612)
Time Spent: 1.5h (was: 1h 20m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919610=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919610
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:17
Start Date: 15/May/24 23:17
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602358744
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
I don't see how not throwing an NPE due to thread synchronization issues
isn't best solved by proper thread synchronization...
With the current fix it could continue writing after the close if the close
is happening on another thread than the write as the values being checked
aren't synced on a barrier so they could be non-null for more than one
execution until a cache flush is forced by some other barrier. It might not NPE
now but it still isn't guaranteed to stop when you intended it to.
Issue Time Tracking
---
Worklog Id: (was: 919610)
Time Spent: 1h 20m (was: 1h 10m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919608=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919608
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:05
Start Date: 15/May/24 23:05
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602351080
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
The goal is to not Throw a npe. Not needed synchronization for that.
Issue Time Tracking
---
Worklog Id: (was: 919608)
Time Spent: 1h 10m (was: 1h)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919607=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919607
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 23:02
Start Date: 15/May/24 23:02
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602349518
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
So why not just add synchronization if your goal is to make the code thread
safe?
Issue Time Tracking
---
Worklog Id: (was: 919607)
Time Spent: 1h (was: 50m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919605=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919605
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 22:10
Start Date: 15/May/24 22:10
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602306503
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
https://github.com/apache/activemq-artemis/blob/14e83faa1bf5523d63755ec54f42cbc1d21affc6/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java#L126-L134
so.. one thread is in resetClose.. another thread is on the tryDeliver...
closed is only set to true at the end of the statement...
as a result you could the NPE.
you may say set closed first...but still I don't feel like this is
completely atomic without added synchronization... however I don't want
synchrnoization here.. just a local copy and checking it should be enough for
me.
I plan to add a test on this.
Issue Time Tracking
---
Worklog Id: (was: 919605)
Time Spent: 50m (was: 40m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919604=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919604
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 22:08
Start Date: 15/May/24 22:08
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602304910
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
If I checked just closed, I guess you could still hit the NPE. You could
check the closed variable.. but I don't know how to get rid of the possible NPE
here without adding synchronization.
The NPE will be just an annoyance since it's closing anyway.. but I was
asked to mitigate the NPE.
Issue Time Tracking
---
Worklog Id: (was: 919604)
Time Spent: 40m (was: 0.5h)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919579=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919579
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 18:22
Start Date: 15/May/24 18:22
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1602074233
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
That would make more sense as the closed indicator is the only volatile in
the mix and would generally convey the state in a timely manner. Copying the
other resources local is fine but doesn't pass a barrier so they still aren't
the best indicator of closedness.
Issue Time Tracking
---
Worklog Id: (was: 919579)
Time Spent: 0.5h (was: 20m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?focusedWorklogId=919576=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919576
]
ASF GitHub Bot logged work on ARTEMIS-3622:
---
Author: ASF GitHub Bot
Created on: 15/May/24 17:37
Start Date: 15/May/24 17:37
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4909:
URL: https://github.com/apache/activemq-artemis/pull/4909#discussion_r1602019436
##
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTConnectionManager.java:
##
@@ -176,33 +174,27 @@ ServerSessionImpl createServerSession(String username,
String password, String v
return (ServerSessionImpl) serverSession;
}
- void disconnect(boolean failure) {
+ synchronized void disconnect(boolean failure) {
if (session == null || session.getStopped()) {
return;
}
- synchronized (session.getState()) {
Review Comment:
This seems fine in terms of protecting the connect+disconnect calls similar
to before...but, are there other areas synchronising on and accessing or
manipulating the session state that might no longer be protected as before that
still need to be?
Issue Time Tracking
---
Worklog Id: (was: 919576)
Time Spent: 20m (was: 10m)
> MQTT can deadlock on client connection / disconnection
> --
>
> Key: ARTEMIS-3622
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3622
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
>Affects Versions: 2.19.0
> Environment: Using the latest java 17 and artemis 2.19 but looking at
> the code, it should affect 2.20 as well.
>Reporter: Marcelo Takeshi Fukushima
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It seems that the {{MQTTProtocolHandler}} and {{MQTTConnectionManager}} are
> on a racing condition and can deadlock themselves on misbehaving clients. I'm
> including the relevant stack trace (ignore thread 11 that is just waiting for
> the lock).
> Looking at the relevant code, it seems that the clean-up thread (88 on the
> {{{}MQTTFailureListener{}}}) starts cleaning up the session state and then
> the session, but when {{MQTTSession.stop}} calls
> {{{}MQTTSessionState.clear{}}}, the session state is no longer the same (a
> racy connection has replaced the session state with a brand new under the
> same client-id).
> I think the methods connect and disconnect on the {{MQTTConnectionManager}}
> could be marked as synchronized as a whole, to prevent racy connects /
> disconnects (but since I don't know all the ins and outs of the code, you
> guys might have a better fix).
> {noformat}
> Found one Java-level deadlock:
> =
> "Thread-11
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> waiting to lock monitor 0x7f6d003368c0 (object 0x00045f29f240, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState),
> which is held by "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)"
> "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> waiting to lock monitor 0x7f6d00336a80 (object 0x00045f2a1068, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSession),
> which is held by "Thread-88
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=0.0.0.0-212232499)"
> "Thread-88
> (ActiveMQ-remoting-threads-ActiveMQServerImpl::name=0.0.0.0-212232499)":
> waiting to lock monitor 0x7f6d003368c0 (object 0x00045f29f240, a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState),
> which is held by "Thread-24
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)"
> Java stack information for the threads listed above:
> ===
> "Thread-11
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnectionManager.disconnect(MQTTConnectionManager.java:150)
> - waiting to lock <0x00045f29f240> (a
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTSessionState)
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTFailureListener.connectionFailed(MQTTFailureListener.java:37)
> at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTConnection.fail(MQTTConnection.java:150)
> at
>
[jira] [Work logged] (ARTEMIS-4771) NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
[
https://issues.apache.org/jira/browse/ARTEMIS-4771?focusedWorklogId=919571=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919571
]
ASF GitHub Bot logged work on ARTEMIS-4771:
---
Author: ASF GitHub Bot
Created on: 15/May/24 17:12
Start Date: 15/May/24 17:12
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4932:
URL: https://github.com/apache/activemq-artemis/pull/4932#discussion_r1601973117
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPLargeMessageWriter.java:
##
@@ -170,16 +170,26 @@ private void resume() {
}
private void tryDelivering() {
+
+ final Delivery localDelivery = delivery;
+ final MessageReference localReference = reference;
+ final LargeBodyReader localBodyReader = largeBodyReader;
+
+ if (localDelivery == null || localReference == null || localBodyReader
== null) {
+ logger.debug("Write got closed before tryDelivering was called");
+ return;
+ }
Review Comment:
Cant we just check 'closed' here instead of all these changes and checks?
Issue Time Tracking
---
Worklog Id: (was: 919571)
Time Spent: 20m (was: 10m)
> NPE between AMQPLargeMessageWriter::tryDelivering and resetClose
>
>
> Key: ARTEMIS-4771
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4771
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is using RedHat's bits:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.qpid.proton.engine.Delivery.getTag()" because "this.delivery" is
> null
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter.tryDelivering(AMQPLargeMessageWriter.java:174)
> ~[artemis-amqp-protocol-2.33.0.redhat-9.jar:2.33.0.redhat-9]
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
> ~[netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
> [netty-transport-classes-epoll-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [netty-common-4.1.108.Final-redhat-1.jar:4.1.108.Final-redhat-1]
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.33.0.redhat-9.jar:2.33.0.redhat-9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-4772?focusedWorklogId=919533=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919533 ] ASF GitHub Bot logged work on ARTEMIS-4772: --- Author: ASF GitHub Bot Created on: 15/May/24 14:37 Start Date: 15/May/24 14:37 Worklog Time Spent: 10m Work Description: mnapierajAvSystem opened a new pull request, #4935: URL: https://github.com/apache/activemq-artemis/pull/4935 (no comment) Issue Time Tracking --- Worklog Id: (was: 919533) Remaining Estimate: 0h Time Spent: 10m > Expose registered broker plugin class names in JMX > -- > > Key: ARTEMIS-4772 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4772 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.33.0 >Reporter: Marek Napieraj >Priority: Minor > Labels: features, pull-request-available > Fix For: 2.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Make broker plugin class names available as a JMX Attribute for better > debug/monitoring of Artemis instances. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919531=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919531 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:32 Start Date: 15/May/24 14:32 Worklog Time Spent: 10m Work Description: mnapierajAvSystem closed pull request #4934: ARTEMIS-4745 Expose registered broker plugin class names as JMX Attribute URL: https://github.com/apache/activemq-artemis/pull/4934 Issue Time Tracking --- Worklog Id: (was: 919531) Time Spent: 1h 10m (was: 1h) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919530=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919530 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:19 Start Date: 15/May/24 14:19 Worklog Time Spent: 10m Work Description: mnapierajAvSystem commented on PR #4934: URL: https://github.com/apache/activemq-artemis/pull/4934#issuecomment-2112680407 you are absolutely right. Updating commit message will be enough or create a branch with proper name and new PR is required? Issue Time Tracking --- Worklog Id: (was: 919530) Time Spent: 1h (was: 50m) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 1h > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919527=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919527 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:15 Start Date: 15/May/24 14:15 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4934: URL: https://github.com/apache/activemq-artemis/pull/4934#issuecomment-2112671582 Seems as though you should be referencing [ARTEMIS-4772](https://issues.apache.org/jira/browse/ARTEMIS-4772) in this commit. Issue Time Tracking --- Worklog Id: (was: 919527) Time Spent: 50m (was: 40m) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 50m > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=919525=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919525 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 15/May/24 14:10 Start Date: 15/May/24 14:10 Worklog Time Spent: 10m Work Description: mnapierajAvSystem opened a new pull request, #4934: URL: https://github.com/apache/activemq-artemis/pull/4934 (no comment) Issue Time Tracking --- Worklog Id: (was: 919525) Time Spent: 40m (was: 0.5h) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4772) Expose registered broker plugin class names in JMX
Marek Napieraj created ARTEMIS-4772: --- Summary: Expose registered broker plugin class names in JMX Key: ARTEMIS-4772 URL: https://issues.apache.org/jira/browse/ARTEMIS-4772 Project: ActiveMQ Artemis Issue Type: Improvement Components: JMX Affects Versions: 2.33.0 Reporter: Marek Napieraj Fix For: 2.34.0 Make broker plugin class names available as a JMX Attribute for better debug/monitoring of Artemis instances. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=919470=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919470 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 15/May/24 10:13 Start Date: 15/May/24 10:13 Worklog Time Spent: 10m Work Description: gemmellr merged PR #15: URL: https://github.com/apache/activemq-artemis-console/pull/15 Issue Time Tracking --- Worklog Id: (was: 919470) Time Spent: 10h 40m (was: 10.5h) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10h 40m > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4
[ https://issues.apache.org/jira/browse/ARTEMIS-4680?focusedWorklogId=919465=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-919465 ] ASF GitHub Bot logged work on ARTEMIS-4680: --- Author: ASF GitHub Bot Created on: 15/May/24 09:22 Start Date: 15/May/24 09:22 Worklog Time Spent: 10m Work Description: andytaylor commented on PR #15: URL: https://github.com/apache/activemq-artemis-console/pull/15#issuecomment-2112011157 > All looks good to me! Checking out this PR gave me the opportunity to run the hawtio console for the first time. > > Maybe it would be worth it to split the PR into a few commits though, I feel that there is space for at least one commit for the dependencies update and one commit for the UI fixes. I have split it into 2 commits as suggested Issue Time Tracking --- Worklog Id: (was: 919465) Time Spent: 10.5h (was: 10h 20m) > Upgrade the console to use HawtIO 4 > --- > > Key: ARTEMIS-4680 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4680 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: console-1.0.0 > > Time Spent: 10.5h > Remaining Estimate: 0h > > The current console is based upon HawtIO 1 which in turn is built on > Bootstrap. Bootstrap is old and no longer actively being maintained. > > This improvement is to migrate the current console to use HawtIO 4 which i > based on Typescript, react and Patternfly. > > As it can run standalone and be built seperately, this will be released > independently from [https://github.com/apache/activemq-artemis-console] and > the output later consumed in Artemis releases (similar to artemis-native). -- This message was sent by Atlassian Jira (v8.20.10#820010)
