On 6/23/22 10:50, Richard Bergmann wrote:
Thank you, yes. I did read the doc, especially the:if the sender has no real STOMP frame to send, it MUST send an end-of-line (EOL) Not sure what that would look like given that spec sez the broker can kill the connection if it doesn't know how to process the message.
Given the specification says an EOL constitutes a heart beat one could assume the broker would process it as such.
What I wouldn't give for actual code examples! :p
here you go: socket.write("\n");
________________________________ From: Timothy Bish <tabish...@gmail.com> Sent: Thursday, June 23, 2022 10:42 AM To: users@activemq.apache.org <users@activemq.apache.org> Subject: Re: [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. On 6/23/22 10:21, Richard Bergmann wrote: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 withinhttps://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2Flatest%2Fstomp.html&data=05%7C01%7CRBERGMANN%40colsa.com%7Ce0a1ab147ca443c6050208da5526a6bf%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915921763831553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yD7bu2G6emDa%2FGl2TpN7CPJygN5GEflmnS7WJ3FDsUE%3D&reserved=0 (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!!!!!See bullet point 2 from the spec in regards to heart beats: Regarding the heart-beats themselves, any new data received over the network connection is an indication that the remote end is alive. In a given direction, if heart-beats are expected every |<n>| milliseconds: * the sender MUST send new data over the network connection at least every |<n>| milliseconds * if the sender has no real STOMP frame to send, it MUST send an end-of-line (EOL) * if, inside a time window of at least |<n>| milliseconds, the receiver did not receive any new data, it MAY consider the connection as dead * because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error marginSorry, 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 isstill 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%7Ce0a1ab147ca443c6050208da5526a6bf%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915921763831553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MgXBFTRPW2DEyYLOvkROc8Wz2YT2OH%2B1d6SsOuYCKV4%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-- Tim Bish ________________________________ 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
-- Tim Bish
