OK, here's some useful info... I used:
tcpdump tcp port 61616 and host dell7
I noticed that if I use:
?wireFormat.maxInactivityDurationInitialDelay=30000
in my client to extend the timeout to 30 seconds instead of the
default 10 seconds, then my client (running on dell7) completes its
message send without the "Wire Format Negotiation Timeout" error.
So I ran it both ways (10 seconds and 30 seconds) and monitored the
output from tcpdump in each case. When the error occurs, there is
still two-way communication going on between the client and the
broker, but the number of lines from tcpdump is much shorter
(because a connection is made, but creating a session fails). When
I extend the InactivityDelay to 30 seconds, and the client completes
normally (but takes more than 20 seconds to send a 40-character text
string), then the amount of tcpdump output increases by a factor of
10!
In a well-tuned system/network, I would think that sending a
40-character text string to ActiveMQ would be nearly instantaneous
from a human's perspective, right?
What I learned from this is that I can reduce the occurrences of the
error by increasing the amount of patience (e.g., 30 seconds) my
client app is to have, but I fear this may also cause some "bogging
down" side effects since each message attempt may take up to 30
seconds. I also learned that our networking issues may be more
acute than I realized.
What else I learned is that a connection is established nearly
instantaneously, but creating the session is the part that often
takes more than 20 seconds (and fails if it takes more than
maxInactivityDurationInitialDelay). So if my network is slow, why
would the connection occur instantaneously, but the creation of the
session take so long?? It's not the sending of the text string that
is the problem, but the creation of the session... Is there
something I can control that affects how long it takes to create a
session? Intuitively, I would have thought that the most
time-consuming part of sending the message is the actual sending of
the text string, not creating the session. Does this point to a bug
in ActiveMQ's createSession() method??
Thanks for the help!
Mark
On 5/13/2013 3:40 PM, ceposta [via
ActiveMQ] wrote:
You can use wireshark (or tcpdump) on the broker
machine to see if the
client's WireFormatInfo is coming through and whether the broker
is sending
one. Wireshark does have a built in activemq command codec so you
can see
the command objects going through. You can also try things like
ping or
traceroute to see if the client can get to the broker.
mark_fenbers.vcf (360 bytes)
<http://activemq.2283324.n4.nabble.com/attachment/4666990/0/mark_fenbers.vcf>
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666990.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
