[ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901245&page=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)

Reply via email to