For the embedded 2.10.1 broker case, are you saying that connections failed
when made from other threads in the process in which the broker was
embedded? If so, that would seem to rule out the network, since traffic
would never leave the host.
You mentioned capturing a stack trace, but have you do
> Obviously the delivery failed after the server lost the connection to the
consumer...
Based on the logs you provided I don't see any direct link between the
connection timeout and the redelivery failure. In fact, when I read your
initial message I wondered why you included that log entry since i
Thank you for your response.
There is still a few things that are not clear for me.
Obviously the delivery failed after the server lost the connection to
the consumer, so i don't understand how, if the redelivery count was
updated by an opaque client side delivery, the server got an up to date
co
As far as I can tell you're seeing the overlap between how ActiveMQ Artemis
handles redelivery and how the OpenWire JMS client (written for ActiveMQ
5.x) handles redelivery. To simplify, ActiveMQ Artemis handles redelivery
on the broker (configured via address-settings), but the OpenWire JMS
client
Hello (again),
I'm trying to find the root cause of a significant number of failed
connexions attempts / broken existing connections on an artemis broker.
The issue have been produced on an embedded artemis 2.10.1 and a
standalone 2.16.0 (tomcat9, openjdk11)
Two type of errors occurs : timeouts
Hello,
I have an unexpected behavior on redelivery with artemis.
The documentation states that redelivery is attempted 10 times by
default and that -1 means infinite
(https://activemq.apache.org/components/artemis/documentation/2.10.1/undelivered-messages.html)
(I checked the documentation matc
