[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: ActiveMQ DLQ issues
From:       Tim Bain <tbain () alumni ! duke ! edu>
Date:       2017-11-20 13:45:22
Message-ID: CAPVVMa9VZ6rXy--bi1Ck80xD4Xp5qztH96A5Uorf4D+uaztiWw () mail ! gmail ! com
[Download RAW message or body]


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.tully@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 <august@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
> >
>


[prev in list] [next in list] [prev in thread] [next in thread]