I am set up to receive the heartbeat event on-heartbeat, but it is never fired.
Heartbeat makes sense, and I did a bit of digging on that, but the "STOMP heart-beating and connection-ttl" section within https://activemq.apache.org/components/artemis/documentation/latest/stomp.html (which think I read maybe 50 times over the last two days?) basically sez (1) you need STOMP 1.1 or 1.2 (1.0 is the default) (2) you need to send a heartbeat header (3) you need to respond with a heartbeat But nowhere is does is specify WHAT a heartbeat message is!!!! Yes (and just know), massive Googling presents me with no examples of HOW to do this. As I am using a basic STOMP Python connection (presumably 1.0), I am HAPPY to send unsolicited heartbeats to the broker every, say, 30 seconds, but I'm left wanting for just WHAT that heartbeat call is!!!!! Sorry, kinda frustrated here . . . ________________________________ From: Justin Bertram <jbert...@apache.org> Sent: Thursday, June 23, 2022 9:50 AM To: users@activemq.apache.org <users@activemq.apache.org> Subject: [External] - Re: How to avoid AMQ229014 TTL "dump" for a "patient" Python 3 Stomp Listener CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > Is there a more acceptable way to alert the broker that the listener is still alive and well but just being patient? Yes. STOMP already has this via heartbeating [1]. Does your Python client support heartbeating? If so, are you configuring it? Justin [1] https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fstomp.github.io%2Fstomp-specification-1.2.html%23Heart-beating&data=05%7C01%7CRBERGMANN%40colsa.com%7C635e817e829f4163aed408da551f6e82%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915890753976094%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qu6RHSKJ756FmPM3wH%2FfGhHfWt%2BQb3gp7yEeScO0xgc%3D&reserved=0 On Thu, Jun 23, 2022 at 7:56 AM Richard Bergmann <rbergm...@colsa.com.invalid> wrote: > I migrated my application from Classic to Artemis, and now my listeners > are being summarily disconnected by the broker on a TTL timeout. > > My use case is that I have listeners (subscribers) that are launched as a > service and patiently wait (could be for days!!!!) for messages to arrive > on a work queue. Furthermore, the work to be done can take perhaps up to > an hour . . . well past the default TTL timeout of 60 seconds. This was > not an issue in Classic, but certainly is in Artemis. > > My solution was to bump the STOMP acceptor timeout to something > stratospheric (e.g., 10,000,000,000), but this just feels . . . icky! > > I've seen a number of threads recommend doing a "connect and subscribe" > loop in the on-disconnect event, but I have a bad feeling about this if the > listener is working on a message that is either NACKed on the disconnect, > or the ACK fails because the work was completed between the disconnect and > the reconnect. In other words, this also feels icky! > > Is there a more acceptable way to alert the broker that the listener is > still alive and well but just being patient? For example, is there a NOOP > call that can be made to the broker every, say, 30 seconds, to say "I'm > still here! Please don't kill me!!!"? Since the listener may be in the > throes of a long-running process, I can see having the listener spawn a > thread that sends the "I'm alive!" message every 30 seconds, then, > terminate the thread on a successful shutdown. That way the broker can > kill legitimately "dead" listeners by keeping the reasonable 60 second > timeout, but not assassinate my legitimate patient listeners. > > Thank you! :) > ________________________________ > The information contained in this e-mail and any attachments from COLSA > Corporation may contain company sensitive and/or proprietary information, > and is intended only for the named recipient to whom it was originally > addressed. If you are not the intended recipient, any disclosure, > distribution, or copying of this e-mail or its attachments is strictly > prohibited. If you have received this e-mail in error, please notify the > sender immediately by return e-mail and permanently delete the e-mail and > any attachments. > > > COLSA Proprietary > ________________________________ The information contained in this e-mail and any attachments from COLSA Corporation may contain company sensitive and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments. COLSA Proprietary
