Thanks for the detailed response!
Unfortunately I don't know when the out of memory error happened. My logs
were full of them. Messages started appearing
in the DLQ about 21:00, and the logs with the OOM start at around 05:00 the
day after.
On the producer end, I connect to ActiveMQ using a ActiveMQConnectionFactory
with the URL set to `failover:(tcp://localhost:61616)`. I create the
connection by calling `createConnection` on this factory. I call
`setClientId` on the connection before I call `start` on it to connect. To
create the session, I call `createSession(false,
javax.jms.Session.AUTO_ACKNOWLEDGE)` on the connection object. I then call
`createProducer` on the session, with the destination being `new
ActiveMQTopic("VirtualTopic.MyTopicNameHere")`. The message I send is
created by calling `createTextMessage` on the session, and I pass a string
to it, containing some XML. Then I call `send` on the producer, with the
message I just created. This producer uses
"org.apache.activemq:activemq-core:5.7.0".
The ActiveMQ broker that I connect to runs on version 5.14.4.
I don't override any defaults or set any properties on the connection or the
session or the producer or the message, so pretty much everything seems to
be running in default configuration as far as I can tell.
The topic I posted messages to, "VirtualTopic.MyTopicNameHere" (which isn't
the real name, obviously), where the messages ended up in DLQ, is a topic
that is automatically created by the producer. I don't have any extra config
for it in the activemq config files.
Your theory about the consumer for that topic on the remote broker is
interesting. Things went a bit haywire so we restarted some things here and
there before we were able to fully collect information about what happened.
The broker that we configured as a network connector and that had
VirtualTopic.MyTopicNameHere statically included, seemed to have problems as
well. I noticed, for example, that this remote broker didn't accept new
connections, until we restarted it. So it's possible that the root cause is
that the remote broker failed, and this caused things to go haywire on the
local broker.
I was a bit surprised that messages to a topic ended up on a DLQ, since if
nobody consumes a message on a topic, the message is just discarded and the
world moves on. But you're saying that if a topic is statically included as
a destination in a network connector, and the broker cannot access that
network connector, those messages end up in the DLQ of the local broker?
That makes sense to me, at least. In that case, I suppose the only input I
have here is that it would be nice if the broker that puts the message on
the DLQ has a more informative reason in the dlqDeliveryFailureCause
attribute :)
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
