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
