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.
What I wouldn't give for actual code examples! :p
________________________________
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 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%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
