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 Abel |
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 Bruce answered 22 Dec '10, 14:38  bsnyder Thank you this is very helpful. Let me get with the developers and see what they say. (23 Dec '10, 09:26) Marc Abel |
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?
I see 1184 out of 5037 packets which is closer to 25%. These packets are all duplicate acks and out of order messages.
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.
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?