[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=908807=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-908807
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 07/Mar/24 16:45
Start Date: 07/Mar/24 16:45
Worklog Time Spent: 10m
Work Description: jbertram merged PR #4752:
URL: https://github.com/apache/activemq-artemis/pull/4752
Issue Time Tracking
---
Worklog Id: (was: 908807)
Time Spent: 3h 40m (was: 3.5h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=902497=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-902497
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 30/Jan/24 05:31
Start Date: 30/Jan/24 05:31
Worklog Time Spent: 10m
Work Description: 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. :-)
Issue Time Tracking
---
Worklog Id: (was: 902497)
Time Spent: 3.5h (was: 3h 20m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=902429=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-902429
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 29/Jan/24 21:39
Start Date: 29/Jan/24 21:39
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 902429)
Time Spent: 3h 20m (was: 3h 10m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=902428=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-902428
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 29/Jan/24 21:38
Start Date: 29/Jan/24 21:38
Worklog Time Spent: 10m
Work Description: 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?
Issue Time Tracking
---
Worklog Id: (was: 902428)
Time Spent: 3h 10m (was: 3h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.33.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901347=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901347
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 24/Jan/24 07:29
Start Date: 24/Jan/24 07:29
Worklog Time Spent: 10m
Work Description: 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()`
Issue Time Tracking
---
Worklog Id: (was: 901347)
Time Spent: 3h (was: 2h 50m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901280=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901280
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 21:10
Start Date: 23/Jan/24 21:10
Worklog Time Spent: 10m
Work Description: 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?
Issue Time Tracking
---
Worklog Id: (was: 901280)
Time Spent: 2h 50m (was: 2h 40m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901262=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901262
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 19:23
Start Date: 23/Jan/24 19:23
Worklog Time Spent: 10m
Work Description: 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?
Issue Time Tracking
---
Worklog Id: (was: 901262)
Time Spent: 2h 40m (was: 2.5h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901259=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901259
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 19:13
Start Date: 23/Jan/24 19:13
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901259)
Time Spent: 2.5h (was: 2h 20m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901247=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901247
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 17:48
Start Date: 23/Jan/24 17:48
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901247)
Time Spent: 2h 20m (was: 2h 10m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901246=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901246
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 17:39
Start Date: 23/Jan/24 17:39
Worklog Time Spent: 10m
Work Description: 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`.
Issue Time Tracking
---
Worklog Id: (was: 901246)
Time Spent: 2h 10m (was: 2h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901245=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901245
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 17:37
Start Date: 23/Jan/24 17:37
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901245)
Time Spent: 2h (was: 1h 50m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901242=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901242
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 17:14
Start Date: 23/Jan/24 17:14
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901242)
Time Spent: 1h 50m (was: 1h 40m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901146=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901146
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 09:04
Start Date: 23/Jan/24 09:04
Worklog Time Spent: 10m
Work Description: jsmucr commented on PR #4752:
URL:
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905601738
I've added a `MessageReferenceImpl` leak test.
Issue Time Tracking
---
Worklog Id: (was: 901146)
Time Spent: 1h 40m (was: 1.5h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901115=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901115
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 05:38
Start Date: 23/Jan/24 05:38
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901115)
Time Spent: 1.5h (was: 1h 20m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901112=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901112
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 05:33
Start Date: 23/Jan/24 05:33
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901112)
Time Spent: 1h 20m (was: 1h 10m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901106=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901106
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 23/Jan/24 04:28
Start Date: 23/Jan/24 04:28
Worklog Time Spent: 10m
Work Description: 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?
Issue Time Tracking
---
Worklog Id: (was: 901106)
Time Spent: 1h 10m (was: 1h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901029=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901029
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 22/Jan/24 20:00
Start Date: 22/Jan/24 20:00
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901029)
Time Spent: 1h (was: 50m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901025=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901025
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 22/Jan/24 19:51
Start Date: 22/Jan/24 19:51
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901025)
Time Spent: 50m (was: 40m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901023=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901023
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 22/Jan/24 19:43
Start Date: 22/Jan/24 19:43
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901023)
Time Spent: 40m (was: 0.5h)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901022=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901022
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 22/Jan/24 19:42
Start Date: 22/Jan/24 19:42
Worklog Time Spent: 10m
Work Description: 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 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)
Issue Time Tracking
---
Worklog Id: (was: 901022)
Time Spent: 0.5h (was: 20m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901021=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901021
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 22/Jan/24 19:42
Start Date: 22/Jan/24 19:42
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 901021)
Time Spent: 20m (was: 10m)
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4579) Add the *FirstMessage* API for scheduled messages
[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=900585=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900585
]
ASF GitHub Bot logged work on ARTEMIS-4579:
---
Author: ASF GitHub Bot
Created on: 19/Jan/24 05:57
Start Date: 19/Jan/24 05:57
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
---
Worklog Id: (was: 900585)
Remaining Estimate: 0h
Time Spent: 10m
> Add the *FirstMessage* API for scheduled messages
> -
>
> Key: ARTEMIS-4579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.31.2
>Reporter: Jan Šmucr
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
