cshannon commented on issue #2404: URL: https://github.com/apache/activemq/issues/2404#issuecomment-5204962295
Flushing outstanding acks probably makes sense anyways, but the motivation seems weird to me. (trying to work around stale connections) Anytime you do batching it usually makes sense to have a time limit to flush so you don't wait forever. In fact, I've had to configure bridges to lower the percentage for bridges that are not as busy just so we don't show pending acks for a long time in metrics. I am mostly just curious why you need to use this as a work around for bad connections? Does the inactivity monitor not work for your use case? That's the tool to detect bad connections and to cause resetting if there are no heart beats so it seems strange to rely on this for that reason. I would think if the connection is bad the broker would stop getting heart beats. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
