Nice investigation!
> > 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? > > Yes, it should be super fast. > 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. > Yah, increasing the inactivity could provide helpful, but finding the root cause of network slowdown (firewall?? overloaded routers/switches?) would be best especially if you can control it or fix it. > > 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?? > Well, what happens when you "create a connection" but don't start it, it will open the transport and start wire format negotiation... when you do connection.start().. or when you try to open a session, it will ensure that the connection is properly constructed, which is the expensive part. So sessions by themselves are cheap enough as long as the connection is up. > > 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. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
