You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by fenbers <Ma...@noaa.gov> on 2013/05/13 19:50:10 UTC
Wire Format Negotiation Timeout -- Say what??
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.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by fenbers <Ma...@noaa.gov>.
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) <http://activemq.2283324.n4.nabble.com/attachment/4666984/0/mark_fenbers.vcf>
--
View this message in context: http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4666984.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by fenbers <Ma...@noaa.gov>.
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) <http://activemq.2283324.n4.nabble.com/attachment/4667003/0/mark_fenbers.vcf>
--
View this message in context: http://activemq.2283324.n4.nabble.com/Wire-Format-Negotiation-Timeout-Say-what-tp4666972p4667003.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by Christian Posta <ch...@gmail.com>.
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 <Ma...@noaa.gov> 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
> 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. 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) <
> 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
Re: Wire Format Negotiation Timeout -- Say what??
Posted by fenbers <Ma...@noaa.gov>.
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:
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. 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) <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.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by Christian Posta <ch...@gmail.com>.
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
Re: Wire Format Negotiation Timeout -- Say what??
Posted by fenbers <Ma...@noaa.gov>.
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.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by Christian Posta <ch...@gmail.com>.
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 <Ma...@noaa.gov> wrote:
>
>
>
>
>
> 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
>
> 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
Re: Wire Format Negotiation Timeout -- Say what??
Posted by fenbers <Ma...@noaa.gov>.
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
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.
Re: Wire Format Negotiation Timeout -- Say what??
Posted by Christian Posta <ch...@gmail.com>.
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 <Ma...@noaa.gov> 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