> 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://stomp.github.io/stomp-specification-1.2.html#Heart-beating 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 >
