Thank you Justin. It's just now becoming apparent to me that the heartbeating mechanism is built into the client connection, i.e., I don't have to do anything on the on-heartbeat event. Doh!
>From what I've read I need to create a Connection12 to make all this go. So >now I will proceed to try to get all this working. Thank you for your help and your patience. Regards, Rich Bergmann ________________________________ From: Justin Bertram <jbert...@apache.org> Sent: Thursday, June 23, 2022 11:01 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. Heart-beating is something that your client implementation should provide for you automatically. You shouldn't need to send your own heart-beats manually. The client should also provide a way to configure the heart-beating on the initial connection so that it can send the proper header on the CONNECT frame. Does your Python STOMP client support heart-beating? The fact that you're not receiving any heart-beats indicates that either your client doesn't support it or you're not configuring it properly. Justin On Thu, Jun 23, 2022 at 9:22 AM Richard Bergmann <rbergm...@colsa.com.invalid> 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 within > https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Factivemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2Flatest%2Fstomp.html&data=05%7C01%7CRBERGMANN%40colsa.com%7Cfb348f55351b4d9d11ab08da552942cb%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915932981513562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dVeuxnvIg0l7YWPTv03pgLC%2FtASlTBufFl1CnK3%2BwAo%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!!!!! > > 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%7Cfb348f55351b4d9d11ab08da552942cb%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637915932981513562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QZ5eaXPjyaTvWi2w3YuQ0BNS%2FHvO1XZWppsysQgcAnQ%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 > ________________________________ 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
