Gosh, and I thought I was the snarky one! :)
I meant in the context of a Python STOMP connection, e.g., conn.send("\n") or
conn.heartbeat().
As I just replied to Justin, it just wasn't apparent to me that the heartbeat
mechanism was baked into the client connection.
I think I have enough to proceed for now.
Thanks again.
Regards,
Rich
________________________________
From: Timothy Bish <tabish...@gmail.com>
Sent: Thursday, June 23, 2022 10:56 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: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%7Cb19ef876378b4633474408da552898bc%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915930131393413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UXuwp0pmrefrqHtznCujxZalP%2B9xsBjByYrViRKtlM%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 margin
>
>
>
>> 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%7Cb19ef876378b4633474408da552898bc%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915930131393413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hmsT8rrtO%2Fo%2Bghr4Fbc9isqKETYtZiuYJRgDhe25JcI%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
________________________________
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
