Thanks Gary. I was convinced that the default configuration did not contain any of the message-discarding options from the slow consumers page I linked to; I'm not sure where I got that idea. But that explanation makes more sense than my wild theory about the no-consumer behavior of statically included virtual topics.
Tim On Nov 20, 2017 4:54 AM, "Gary Tully" <gary.tu...@gmail.com> wrote: > dlqDeliveryFailureCause java.lang.Throwable: TopicSubDiscard. > ID:localhost->fmiuseastp01-63022-1486246061090-100948:1:1:2 > > The cause indicates the a subscriber is full and has been configured to > discard messages[1]. See policyEntry from the default config [2] > > https://github.com/apache/activemq/blob/41a100766c19655816d575841ba559 > d33c63313d/activemq-broker/src/main/java/org/apache/ > activemq/broker/region/TopicSubscription.java#L718 > > https://github.com/apache/activemq/blob/41a100766c19655816d575841ba559 > d33c63313d/assembly/src/release/conf/activemq.xml#L55 > > On Mon, 20 Nov 2017 at 11:08 augustl <aug...@augustl.com> wrote: > > > 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 > > >
