This is a static archive of our old Q&A Site. Please post any new questions and answers at

Is it the network? ActiveMQ problem


Tracking an issue with apache/activeMQ where some messages are expiring in queue rather than being retrieved by the member servers.

I don't see many errors on the associated interfaces and I seem to have connectivity between all the servers any time I check. I did 5 minute capture of all the TCP 18080 traffic and I see alot of TCP DUP ACK and TCP resets. In about 5000 packets I had:

2591 Chats 835 Notes 349 warnings 0 errors

Does this look normal or suspect? I know dup acks can represent packet loss. If I assume all of those 349 warnings are packet loss that is about 12.5%.

Thanks in advance for any help.

asked 21 Dec '10, 07:27

Marc%20Abel's gravatar image

Marc Abel
accept rate: 0%

You can't have a 12% pkt loss. That's an impossibly high number. If you type "tcp.analysis.flags" display filter, what do you see?

(22 Dec '10, 17:19) hansangb

I see 1184 out of 5037 packets which is closer to 25%. These packets are all duplicate acks and out of order messages.

(23 Dec '10, 09:25) Marc Abel

It's possible that you have a duplex mismatch causing pkt loss. Have you ruled that out? Also, keep in mind that duplicate acks are just that...duplicates. So you may have 25% "error/notices" but you don't have 25% pkt loss.

There are other possible answers, but rule out the duplex mismatch first.

(23 Dec '10, 16:51) hansangb

If you have a load of duplicate acks and out-of-order packets, then they are most likely duplicates. This can be caused by the way the capture file has been generated (did you span a vlan and inlcuded both directions for instance?).

Could you run "editcap -d <infile> <outfile>" on the file to remove duplicate packets? Do you still see that many duplicate acks and out-of-order packets when you load <outfile> in Wireshark?

(24 Dec '10, 17:51) SYN-bit ♦♦

One Answer:


This is a feature from the JMS spec. The reason that messages expire in the queue instead of being delivered to consumers is because they have been marked with a timeToLive by the sender. Check out the JMS docs on this feature via the MessageProducer.html#setTimeToLive() method. By setting the timeToLive on a message, this instructs ActiveMQ to only hold the message for the given amount of time. If the message is not consumed in that amount of time, then it is expired by ActiveMQ and discarded, i.e., consumers will not receive it.


answered 22 Dec '10, 14:38

bsnyder's gravatar image

accept rate: 0%

Thank you this is very helpful. Let me get with the developers and see what they say.

(23 Dec '10, 09:26) Marc Abel