Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: error (athena.apache.org: local policy)
Date: Mon, 13 May 2013 15:10:41 -0700 (PDT)
From: fenbers <Mark.Fenbers@noaa.gov>
To: users@activemq.apache.org
Message-ID: <519164F3.9080303@noaa.gov>
In-Reply-To: 
 <CAKS7T5PD=FY-9MwxrGbELgrE0Ag5KqAJt53SBwQNOYNii1Db1g@mail.gmail.com>
References: <1368467410527-4666972.post@n4.nabble.com>
 <CAKS7T5PG0NRA0Ur1gwkmtozFc4GoEv=eZr_swgN+FTEet=f0eg@mail.gmail.com>
 <519135B4.2000901@noaa.gov>
 <CAKS7T5PD=FY-9MwxrGbELgrE0Ag5KqAJt53SBwQNOYNii1Db1g@mail.gmail.com>
Subject: Re: Wire Format Negotiation Timeout -- Say what??
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_180673_2421074.1368483041188"

------=_Part_180673_2421074.1368483041188
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


    OK, here's some useful info...&nbsp; I used: 
    &nbsp;&nbsp;&nbsp; tcpdump tcp port 61616 and host dell7 
    
    I noticed that if I use: 
    &nbsp;?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.&nbsp;
    So I ran it both ways (10 seconds and 30 seconds) and monitored the
    output from tcpdump in each case.&nbsp; 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).&nbsp; 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.&nbsp; 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).&nbsp; So if my network is slow, why
    would the connection occur instantaneously, but the creation of the
    session take so long??&nbsp; It's not the sending of the text string that
    is the problem, but the creation of the session...&nbsp; Is there
    something I can control that affects how long it takes to create a
    session?&nbsp; 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.&nbsp; 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.
------=_Part_180673_2421074.1368483041188--