You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by "jsmucr (via GitHub)" <gi...@apache.org> on 2024/01/19 05:57:08 UTC
[PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
jsmucr opened a new pull request, #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752
Alerting on issues with messages not being received properly for a period of time is an uneasy task. We use the `getFirstMessageAge()` command to trigger alerts in Zabbix, and it works as long as there are no consumers.
But this approach fails when there are consumers repeatedly failing to receive a message. That message is getting scheduled for redelivery over and over, and even though there still is an old message in the queue to be reported, it's no longer visible via `getFirstMessage*()` API.
The goal here is to add a set of functions working with messages scheduled for delivery:
```java
getFirstScheduledMessageAsJSON()
getFirstScheduledMessageTimestamp()
getFirstScheduledMessageAge()
```
It may be not the most effective approach but it's quite a convenient one, especially when monitoring a wide set of queues, each with its own set of alerts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906543152
> I need to find out if there's an old message in a queue that's been there for longer than a specified interval, and I'm not allowed to use DLQs for that, because it means a manual intervention on the broker if processing fails too many times.
I'd really like to focus on exactly why you need to know if there's an old message in a queue that's been there for longer than a specified interval?
As noted in my previous comment, in order to have a robust detection of stalled consumers (a.k.a. stuck messages) you _already_ need to look at multiple metrics. If you're relying solely on a metric like `firstMessageAge` you're liable to get false positives. It's just not a good solution. I've long considered deprecating these metrics because folks tend to misunderstand and misuse them.
Keep in mind that we have [slow consumer detection](https://activemq.apache.org/components/artemis/documentation/latest/slow-consumers.html#detecting-slow-consumers) built into the broker.
> I know this method may be heavy but so is our workflow here, which is pretty much based on wasting resources in exchange for usability and easy maintenance.
The problem, as I see it, is that by implementing this method you're going to force this wasting of resources on other users who likely don't want it. As noted previously, it's very common for JMX monitoring tools to fetch the values of every attribute on a given MBean. By adding this method you're implicitly impacting that use-case. Lots of folks use JMX monitoring tools that scan MBeans more than once per minute.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1915617748
> Currently, this basically means to pause the queue, because the GUI doesn't display messages-in-flight.
There **is** a management method which shows details of in-flight messages. It's called `listDeliveringMessagesAsJSON`. That operation, combined with `listScheduledMessagesAsJSON`, should give you everything you need, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906589510
> or... also I would be okay on adding a metric for number of scheduled messages...
We already have that. It's called `scheduledCount`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram merged PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906923931
@jbertram if this was an operation instead of an attribute, then you wouldn't have the issue of scans from JMX providers, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905272950
For awhile I've actually discouraged folks from using the "first message" metrics. [I discussed this on the ActiveMQ users list](https://lists.apache.org/thread/d79n3kbb28k2v4pm7y0kywb5xpvrmpf4) not long ago:
> The `getFirstMessageAge` operation is actually fairly "heavy" and not generally recommended. Furthermore, the age of the first message isn't meaningful in and of itself in this scenario because if the `consumerCount` is 0 then by definition no messages can be stuck. A robust stuck-message detection mechanism must, at the very least, verify that `consumerCount` > 0. Also, instead of using the age of the first message I recommend inspecting `messagesAcknowledged` over time. For example, if the `consumerCount` > 0 and `messagesAcknowledged` remains unchanged for 60 seconds then messages (or more likely *consumers*) may be stuck. If you're using Prometheus then I believe you can use a [range vector selector](https://prometheus.io/docs/prometheus/latest/querying/basics/#range-vector-selectors) for this kind of operation.
At this point I'm against adding "first message" metrics for scheduled messages because it will be a relatively "heavy" operation due to the `synchronized` block. A lot of JMX monitoring tools will simply poll queue MBeans which means this new management method may be invoked *a lot*, especially on a broker with lots of queues. Over the last few years we've seen an increasing number of deployments with many thousands of queues. This is one reason we implemented (and generally recommend using) [pluggable metrics](https://activemq.apache.org/components/artemis/documentation/latest/metrics.html#metrics) which should provide a lighter footprint than JMX and open the door for easier integration with tools that specialize in graphing and alerting (e.g. Prometheus & Grafana).
Would it be possible for you to use existing metrics to solve your problem rather than implementing this new management method?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462333938
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##########
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
}
}
+ protected void notifyScheduledReferencesUpdated() {
+ oldestMessage = null;
+ }
+
+ @Override
+ public MessageReference peekFirstScheduledMessage() {
+ synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+ return null;
+ }
+ if (oldestMessage != null) {
+ return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+ MessageReference ref = scheduledReference.getRef();
+ long refTimestamp = ref.getMessage().getTimestamp();
+ if (refTimestamp < oldestTimestamp) {
+ oldestTimestamp = refTimestamp;
+ result = ref;
+ }
+ }
+ oldestMessage = result;
+ return result;
+ }
+ }
Review Comment:
when / if you apply my suggestion, please squash the commit as yours.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906776157
And as I was composing my previous post, I realized that maybe it's not the idea but the approach that we couldn't agree upon!
> Can't you get this by listScheduledMessages on the control?
That's pretty close actually. In order to be able to monitor the entire cluster via Zabbix I've created sort of a JMX proxy which collects and exposes data from all nodes at once. That proxy is also capable of calling methods, and exposing their results as custom JMX attributes.
---
So basically, the issue you have with the `*FirstMessage*` API is that it's a set of attributes, not a set of operations, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1904700025
my only concern is storing a reference outside the data structure for the first message. treeMap.first() is there for right that purpose.
on the implementation for first(), this is just returning:
public E first() {
return m.firstKey();
}
Which means you can always just return first().
I'm not sure if you need to check for empty or not.. as you would need to double check on that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905601738
I've added a `MessageReferenceImpl` leak test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462744923
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##########
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
}
}
+ protected void notifyScheduledReferencesUpdated() {
+ oldestMessage = null;
+ }
+
+ @Override
+ public MessageReference peekFirstScheduledMessage() {
+ synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+ return null;
+ }
+ if (oldestMessage != null) {
+ return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+ MessageReference ref = scheduledReference.getRef();
+ long refTimestamp = ref.getMessage().getTimestamp();
+ if (refTimestamp < oldestTimestamp) {
+ oldestTimestamp = refTimestamp;
+ result = ref;
+ }
+ }
+ oldestMessage = result;
+ return result;
+ }
+ }
Review Comment:
The `MessageReferenceComparator` uses scheduled delivery time as a measure, so if I'm not mistaken, `scheduledReferences.first()` returns the first message to be delivered, not the oldest message in the queue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906753969
Okay, perhaps I'm not clear enough on what I'm trying to achieve here. And I understand your concerns, so I'll be glad for just another simple solution of my problem if you can think of any.
Here's the use case:
* There's a SLA for every file we run through the broker. It's crucial to know there's a message running around for 10 minutes while it was supposed to leave our system 5 minutes ago. Then there's a five minute trigger which puts us on guard but it's quite common for individual consumers to run into issues with remote customer services (such as connection or gateway timeouts), and it's likely for a warning to disappear before we hit the 10-minute alert.
* There's a 24/7 first level support without any access to underlying systems except for those alerts. These people wake us up at night based on what an alert says. If it says 5 minutes, they wait (_because it's yellow_), once it hits 10 minutes, we already know there's something to take a look at.
* In order to figure out which message is the oldest one that cannot be delivered, we need to look (all sleepy and grumpy) at it's metadata. Currently, this basically means to pause the queue, because the GUI doesn't display messages-in-flight. The time is running out, so a GUI is a must. Unless, of course, there's an attribute, which directly shows the metadata and allows one to act quickly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905325738
@jbertram Only by **very complicated** workarounds. I need to find out if there's an old message in a queue that's been there for a while now, and I'm not allowed to use DLQs for that, because it means a manual intervention on the broker if processing fails too many times.
I know this method is heavy but so is our workflow here, which is pretty much based on wasting resources in exchange for usability and easy maintenance. :-)
I understand your point of view, I really do, but I also find Artemis to be quite an advanced tool all by itself, and that if I slow it down by using a method that is heavy on resources, it's entirely my fault as an operator. Perhaps a page of documentation would be enough to get rid of responsibility here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462332213
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##########
@@ -188,6 +194,34 @@ private void scheduleDelivery(final long deliveryTime) {
}
}
+ protected void notifyScheduledReferencesUpdated() {
+ oldestMessage = null;
+ }
+
+ @Override
+ public MessageReference peekFirstScheduledMessage() {
+ synchronized (scheduledReferences) {
+ if (scheduledReferences.isEmpty()) {
+ return null;
+ }
+ if (oldestMessage != null) {
+ return oldestMessage;
+ }
+ MessageReference result = null;
+ long oldestTimestamp = Long.MAX_VALUE;
+ for (RefScheduled scheduledReference : scheduledReferences) {
+ MessageReference ref = scheduledReference.getRef();
+ long refTimestamp = ref.getMessage().getTimestamp();
+ if (refTimestamp < oldestTimestamp) {
+ oldestTimestamp = refTimestamp;
+ result = ref;
+ }
+ }
+ oldestMessage = result;
+ return result;
+ }
+ }
Review Comment:
```suggestion
@Override
public MessageReference peekFirstScheduledMessage() {
synchronized (scheduledReferences) {
if (scheduledReferences.isEmpty()) {
return null;
}
RefScheduled refScheduled = scheduledReferences.first();
return refScheduled != null ? refScheduled.getRef() : null;
}
}
```
Why not just use scheduledReferences.first()?
I have been dealing with memory leaks in the past, especially the ones that I tested with the leak-tests I wrote, and this would actually eventually leak one message. Besides I think it's more efficient and less error prone to just call getfirst().
in My suggestion I'm still checking for isEmpty(), which I'm not sure it's needed.. something to verify.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jbertram (via GitHub)" <gi...@apache.org>.
jbertram commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1915618925
> ...if this was an operation instead of an attribute, then you wouldn't have the issue of scans from JMX providers, right?
@clebertsuconic, that would be _much_ better, but I still feel like there's a better solution here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1907547658
I've replaced the attributes with this new `peekFirstScheduledMessage()` operation. Maybe I could add `peekFirstMessage()` too, or perhaps rename both to avoid confusion: `peekOldestMessage()`, `peekOldestScheduledMessage()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906586471
I'm also concerned about adding weight here.
I would be okay on adding a method to peek at the first message.. but adding extra processing weight for those who don't need this.. I'm kind of concerned also.
Can't you get this by listScheduledMessages on the control?
or... also I would be okay on adding a metric for number of scheduled messages... (I think it would make sense).. as that would just get the counter directly. and then you can do your processing on listing all the messages if certain metrics apply.
Also, you could tell a lot by the number of redeliveries on the system. you should probably add a warning on your system for the redeliveries counter.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906603874
Right! I looked at the callers on the TreeMap.. I forgot we have the metrics in place.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "clebertsuconic (via GitHub)" <gi...@apache.org>.
clebertsuconic commented on code in PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#discussion_r1462333062
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##########
@@ -51,10 +51,13 @@ public class ScheduledDeliveryHandlerImpl implements ScheduledDeliveryHandler {
// This contains RefSchedules which are delegates to the real references
// just adding some information to keep it in order accordingly to the initial operations
+ // Do not forget to call notifyScheduledReferencesUpdated() when updating the set.
Review Comment:
if you apply my suggestion please remove these calls..
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ScheduledDeliveryHandlerImpl.java:
##########
@@ -51,10 +51,13 @@ public class ScheduledDeliveryHandlerImpl implements ScheduledDeliveryHandler {
// This contains RefSchedules which are delegates to the real references
// just adding some information to keep it in order accordingly to the initial operations
+ // Do not forget to call notifyScheduledReferencesUpdated() when updating the set.
private final TreeSet<RefScheduled> scheduledReferences = new TreeSet<>(new MessageReferenceComparator());
private final QueueMessageMetrics metrics;
+ private MessageReference oldestMessage = null;
Review Comment:
remove this upon accepting my suggestion.. (and please squash the change as yours)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1904713369
Thanks for the review @clebertsuconic, I'll process your suggestions as the first thing tomorrow morning.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] ARTEMIS-4579 Add the *FirstMessage* API for scheduled messages [activemq-artemis]
Posted by "jsmucr (via GitHub)" <gi...@apache.org>.
jsmucr commented on PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1916108015
> There **is** a management method which shows details of in-flight messages. It's called `listDeliveringMessagesAsJSON`. That operation, combined with `listScheduledMessagesAsJSON`, should give you everything you need, right?
It should but there are two things I don't like about this approach:
* The output requires some postprocessing, and therefore it is fairly unusable from the GUI.
* There's nothing that stops the broker from transforming and exporting significant amount of data when all I need is one number.
> I still feel like there's a better solution here
Again, I'm all ears. The bigger picture is that fast response time is a must, or I'm stopping a car assembly line (literally), so every help is much appreciated. :-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org