Wire Format Negotiation Timeout -- Say what??

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Wire Format Negotiation Timeout -- Say what??

fenbers
I'm getting the error shown in the Subject, not at first, but after ActiveMQ has been working just fine for several hours.  Then once it happens, all my clients that interact with the broker reports this error.  I've found this page:
http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html

But none of the 3 issues apply in my case.  Specifically, if the host:port is incorrect, how does it work fine for several hours, then quit in the middle of the night when no one is here?  And I'm not using log4j JMSAppender.  And the broker is not under heavy load.  In fact, it is idle right now and I still get the error.

It must be something else!  Anyone have ideas??  The entire error is below...

Mark

ERROR 2013-05-13 12:08:58,802 [main] SendJMS.StatusProducer: Wire format negotiation timeout: peer did not send his wire format.
javax.jms.JMSException: Wire format negotiation timeout: peer did not send his wire format.
        at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
        at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1409)
        at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1496)
        at org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:325)
        at gov.noaa.ohrfc.SendJMS.StatusProducer.run(StatusProducer.java:92)
        at gov.noaa.ohrfc.SendJMS.SendJMS.main(SendJMS.java:79)
Caused by: java.io.IOException: Wire format negotiation timeout: peer did not send his wire format.
        at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:98)
        at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
        at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
        at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
        at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1380)
        ... 4 more

Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

ceposta
Mark,
When the connection to the broker is first established, the wire format is
negotiated by each side sending it's preferred info. Looks like the client
is sending its info, but not getting anything back. Maybe take a thread
dump to see what's going on on the broker side... can you verify the client
wire info is in fact making it across the network to the broker, or that
the broker's info is making it back to the client? or getting blocked
somehow?




On Mon, May 13, 2013 at 10:50 AM, fenbers <[hidden email]> wrote:

> I'm getting the error shown in the Subject, not at first, but after
> ActiveMQ
> has been working just fine for several hours.  Then once it happens, all my
> clients that interact with the broker reports this error.  I've found this
> page:
>
> http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html
>
> But none of the 3 issues apply in my case.  Specifically, if the host:port
> is incorrect, how does it work fine for several hours, then quit in the
> middle of the night when no one is here?  And I'm not using log4j
> JMSAppender.  And the broker is not under heavy load.  In fact, it is idle
> right now and I still get the error.
>
> It must be something else!  Anyone have ideas??  The entire error is
> below...
>
> Mark
>
> ERROR 2013-05-13 12:08:58,802 [main] SendJMS.StatusProducer: Wire format
> negotiation timeout: peer did not send his wire format.
> javax.jms.JMSException: Wire format negotiation timeout: peer did not send
> his wire format.
>         at
>
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
>         at
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1409)
>         at
>
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1496)
>         at
>
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:325)
>         at
> gov.noaa.ohrfc.SendJMS.StatusProducer.run(StatusProducer.java:92)
>         at gov.noaa.ohrfc.SendJMS.SendJMS.main(SendJMS.java:79)
> Caused by: java.io.IOException: Wire format negotiation timeout: peer did
> not send his wire format.
>         at
>
> org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:98)
>         at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
>         at
>
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
>         at
>
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
>         at
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1380)
>         ... 4 more
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

fenbers
I'm also suspecting it is a network issue, as I surmise you are by the questions you ask.  But my strength is programming, not sysadmin.  So I want to answer your questions, but don't know the RedHat tricks or tools to determine the answers.  Can you hold my hand (figuratively) as to how I can find out if the info is getting blocked?

Mark

On 5/13/2013 2:04 PM, ceposta [via ActiveMQ] wrote:
Mark,
When the connection to the broker is first established, the wire format is
negotiated by each side sending it's preferred info. Looks like the client
is sending its info, but not getting anything back. Maybe take a thread
dump to see what's going on on the broker side... can you verify the client
wire info is in fact making it across the network to the broker, or that
the broker's info is making it back to the client? or getting blocked
somehow?




On Mon, May 13, 2013 at 10:50 AM, fenbers <[hidden email]> wrote:

> I'm getting the error shown in the Subject, not at first, but after
> ActiveMQ
> has been working just fine for several hours.  Then once it happens, all my
> clients that interact with the broker reports this error.  I've found this
> page:
>
> http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html
>
> But none of the 3 issues apply in my case.  Specifically, if the host:port
> is incorrect, how does it work fine for several hours, then quit in the
> middle of the night when no one is here?  And I'm not using log4j
> JMSAppender.  And the broker is not under heavy load.  In fact, it is idle
> right now and I still get the error.
>
> It must be something else!  Anyone have ideas??  The entire error is
> below...
>
> Mark
>
> ERROR 2013-05-13 12:08:58,802 [main] SendJMS.StatusProducer: Wire format
> negotiation timeout: peer did not send his wire format.
> javax.jms.JMSException: Wire format negotiation timeout: peer did not send
> his wire format.
>         at
>
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
>         at
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1409)
>         at
>
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1496)
>         at
>
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:325)
>         at
> gov.noaa.ohrfc.SendJMS.StatusProducer.run(StatusProducer.java:92)
>         at gov.noaa.ohrfc.SendJMS.SendJMS.main(SendJMS.java:79)
> Caused by: java.io.IOException: Wire format negotiation timeout: peer did
> not send his wire format.
>         at
>
> org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:98)
>         at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
>         at
>
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
>         at
>
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
>         at
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1380)
>         ... 4 more
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta



If you reply to this email, your message will be added to the discussion below:
http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666974.html
To unsubscribe from Wire Format Negotiation Timeout -- Say what??, click here.
NAML


mark_fenbers.vcf (360 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

ceposta
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.




On Mon, May 13, 2013 at 11:49 AM, fenbers <[hidden email]> wrote:

>
>
>
>
>
>     I'm also suspecting it is a network issue, as I surmise you are by
>     the questions you ask.&nbsp; But my strength is programming, not
>     sysadmin.&nbsp; So I want to answer your questions, but don't know the
>     RedHat tricks or tools to determine the answers.&nbsp; Can you hold my
>     hand (figuratively) as to how I can find out if the info is getting
>     blocked?
>
>     Mark
>
>     On 5/13/2013 2:04 PM, ceposta [via
>       ActiveMQ] wrote:
>
>      Mark,
>
>       When the connection to the broker is first established, the wire
>       format is
>
>       negotiated by each side sending it's preferred info. Looks like
>       the client
>
>       is sending its info, but not getting anything back. Maybe take a
>       thread
>
>       dump to see what's going on on the broker side... can you verify
>       the client
>
>       wire info is in fact making it across the network to the broker,
>       or that
>
>       the broker's info is making it back to the client? or getting
>       blocked
>
>       somehow?
>
>
>
>
>
>       On Mon, May 13, 2013 at 10:50 AM, fenbers &lt; [hidden email] &gt;
>       wrote:
>
>
>         &gt; I'm getting the error shown in the Subject, not at first,
>         but after
>
>         &gt; ActiveMQ
>
>         &gt; has been working just fine for several hours. &nbsp;Then once
> it
>         happens, all my
>
>         &gt; clients that interact with the broker reports this error.
>         &nbsp;I've found this
>
>         &gt; page:
>
>         &gt;
>
>         &gt;
> http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html
>         &gt;
>
>         &gt; But none of the 3 issues apply in my case. &nbsp;Specifically,
>         if the host:port
>
>         &gt; is incorrect, how does it work fine for several hours, then
>         quit in the
>
>         &gt; middle of the night when no one is here? &nbsp;And I'm not
> using
>         log4j
>
>         &gt; JMSAppender. &nbsp;And the broker is not under heavy load.
> &nbsp;In
>         fact, it is idle
>
>         &gt; right now and I still get the error.
>
>         &gt;
>
>         &gt; It must be something else! &nbsp;Anyone have ideas??
> &nbsp;The entire
>         error is
>
>         &gt; below...
>
>         &gt;
>
>         &gt; Mark
>
>         &gt;
>
>         &gt; ERROR 2013-05-13 12:08:58,802 [main]
>         SendJMS.StatusProducer: Wire format
>
>         &gt; negotiation timeout: peer did not send his wire format.
>
>         &gt; javax.jms.JMSException: Wire format negotiation timeout:
>         peer did not send
>
>         &gt; his wire format.
>
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1409)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1496)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:325)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>         gov.noaa.ohrfc.SendJMS.StatusProducer.run(StatusProducer.java:92)
>
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>         gov.noaa.ohrfc.SendJMS.SendJMS.main(SendJMS.java:79)
>
>         &gt; Caused by: java.io.IOException: Wire format negotiation
>         timeout: peer did
>
>         &gt; not send his wire format.
>
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:98)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; at
>
>         &gt;
>
>         &gt;
>
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1380)
>         &gt; &nbsp; &nbsp; &nbsp; &nbsp; ... 4 more
>
>         &gt;
>
>         &gt;
>
>         &gt;
>
>         &gt;
>
>         &gt;
>
>         &gt; --
>
>         &gt; View this message in context:
>
>         &gt;
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972.html
>         &gt; Sent from the ActiveMQ - User mailing list archive at
>         Nabble.com.
>
>         &gt;
>
>
>
>
>       --
>       *Christian Posta*
>
>       http://www.christianposta.com/blog
>       twitter: @christianposta
>
>        http://www.christianposta.com/blog
>
>
>
>
>
>         If you reply to this email, your
>           message will be added to the discussion below:
>
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666974.html
>
>
>         To unsubscribe from Wire Format Negotiation Timeout -- Say
>         what??, click
>           here .
>         NAML
>
>
>
>
>
>
> mark_fenbers.vcf (360 bytes) <
> http://activemq.2283324.n4.nabble.com/attachment/4666977/0/mark_fenbers.vcf
> >
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666977.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

fenbers
Thanks!  I'm studying up on tcpdump's man page now (about 30 pages of technical details!).  Wireshark isn't installed by default, so I put in a request to have it installed on Tuesday.  I won't be back in until Thursday, so I'll resume my diagnostics then.

The broker and client are on the same local network, and a traceroute takes 1.5 ms for just that one hop!  That's a long time.  Pinging is slow, too, as well as other indications of a slow network, possibly.  So I think we're barking up the right tree, but tracking down the source of any network issues will be an arduous task!  And then we'll have to fix it if we can find it...

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) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

fenbers
In reply to this post by ceposta
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) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

ceposta
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.&nbsp; 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).&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??
>

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
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

fenbers

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.

I typically:
  1. create connection
  2. create session
  3. create producer/consumer
  4. set producer/consumer options
  5. start connection, which is the last thing before returning from the run() method

I find that if I start the connection right after Step 1, then I occasionally see errors complaining that a message was received before a consumer was created.  Starting my connection last seems to resolve that problem.  Are you saying that it is more expensive to do this in my order (above) than it would be if I started my connection right after Step 1??

Mark



mark_fenbers.vcf (360 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

ceposta
No, it's probably the same cost. But the cost is in establishing the
underlying connection, not in creating the session. It just happens that if
you haven't started the connection by the time you try to create the
session, creating the session will set up the underlying connection data
structures before creating a session. Which would explain what you were
seeing.

I would also be curious to understand why starting the connection before
creating the session would get messages delivered. What version are you
using?


On Mon, May 13, 2013 at 4:57 PM, fenbers <[hidden email]> wrote:

>
>
>
>
>
>
>     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
> &nbsp;connection
>       is up.
>
>
>
>     I typically:
>
>       create connection
>       create session
>       create producer/consumer
>       set producer/consumer options
>       start connection, which is the last thing before returning
>         from the run() method
>
>     I find that if I start the connection right after Step 1, then I
>       occasionally see errors complaining that a message was received
>       before a consumer was created.&nbsp; Starting my connection last
> seems
>       to resolve that problem.&nbsp; Are you saying that it is more
> expensive
>       to do this in my order (above) than it would be if I started my
>       connection right after Step 1??
>
>       Mark
>
>
>
>
>
>
> mark_fenbers.vcf (360 bytes) <
> http://activemq.2283324.n4.nabble.com/attachment/4666998/0/mark_fenbers.vcf
> >
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666998.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Reply | Threaded
Open this post in threaded view
|

Re: Wire Format Negotiation Timeout -- Say what??

fenbers
I'm using 5.8.0
Mark

On 5/13/2013 8:29 PM, ceposta [via ActiveMQ] wrote:
No, it's probably the same cost. But the cost is in establishing the
underlying connection, not in creating the session. It just happens that if
you haven't started the connection by the time you try to create the
session, creating the session will set up the underlying connection data
structures before creating a session. Which would explain what you were
seeing.

I would also be curious to understand why starting the connection before
creating the session would get messages delivered. What version are you
using?


mark_fenbers.vcf (360 bytes) Download Attachment