You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by jaya_srini <jy...@Hotmail.com> on 2008/11/20 02:37:56 UTC
Re: Wire format negotiation timeout
Hi
can someone answer my email below?
Basically
What could be some possible causes of the wireformat negotiation not being
established?
Also, Is there a way to set the default timeout parameter from the
Connection URI i.e one of the wireformat.* options?
Currently we are seeing a lot of negotiation timeouts and I would like to
understand why this happens. Could it be related to network connectivity
issues?
thank you
jaya
jaya_srini wrote:
>
> Thanks Joe!
>
> No. we only see this if I send higher than certain number of requests
> (after about 1000 - 2000 concurrent requests)
>
> Couple of questions...
>
> What could be some possible causes of the negitiation not being
> established?
>
> Also, Is there a way to set this timeout parameter from the Connection URI
> i.e one of the wireformat.* options?
>
>
>
> ttmdev wrote:
>>
>> The TransportConnector is used by the broker to listen for and accept
>> connection requests from clients and other brokers. When a connection is
>> initially established, the connection endpoints go through a wireformat
>> negotiation phase. This is explained on this page.
>>
>> http://activemq.apache.org/openwire-version-2-specification.html
>>
>> In your case, I suspect that the broker has sent its wireformat info
>> object and is waiting for the other endpoint (peer) to respond, which it
>> never does within the alloted timeout. The default timeout value is 15
>> seconds (see
>> http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/transport/WireFormatNegotiator.html
>> WireFormatNegotiator.htm ).
>>
>> Do you see the problem with a lighter connection request load?
>>
>> Joe
>>
>>
>>
>> jaya_srini wrote:
>>>
>>> Hello
>>>
>>> We are using ActiveMQ 5.0 and we see these messages in the logs when the
>>> broker is hit with multiple requests (in our case > 1000 concurrent
>>> requests). Each request creates a new connection, sends a message to the
>>> topic and closes the connection. There is also a durable consumer that
>>> gets created once and receives messages asynchrounously from the topic
>>>
>>> ERROR TransportConnector - Could not accept connection :
>>> Wire format
>>> negotiation timeout: peer did not send his wire format.
>>> ERROR TransportConnector - Could not accept connection :
>>> Wire format
>>> negotiation timeout: peer did not send his wire format.
>>>
>>> Can someone explain what the above error message means and how this can
>>> be resolved?
>>>
>>> We are using the following Connect URI
>>>
>>> tcp://localhost:61616?jms.useAsyncSend=true&jms.dispatchAsync=true&wireFormat.maxInactivityDuration=-1
>>>
>>> thank much in advance!
>>> jaya
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20593431.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire format negotiation timeout
Posted by stevec <ba...@hotmail.com>.
Do you have failover and reconnect logic? It might not be a problem for you
if you have this logic. Your client will keep trying to connect and once
connected, will send the message. new connections are not super reliable
(in my opinion). if the listening socket is busy i have seen new
connections fail. since we retry, it is not a big deal... maybe in
10seconds the client will show up on the broker.
the best practice is to have a connection already and just send messages
over it. why open a new connection everytime? also once established the
persistence i think would work better, since you need to actually publish
something for persistence to kick in.
it just depends on what type of reliability you want. you could always
debug your application further to see how long it is taking to do various
tasks. but if you have reconnect logic already and you are not failing
after you connect, then probably you are running OK. just depends on
whether you want to do it the best way and invest that effort
jaya_srini wrote:
>
> Thanks for the response, Steve!
>
> Our broker is not public and the clients are all internal applications and
> not internet users.
>
> we intermittently altho frequently see this error when the client is
> trying to publish a message. Our clients are both publishers and
> subscribers. For every publish, the client creates a new connection, sends
> the message and closes the connection. it receives the message on a
> separate connection.
>
> Our clients also do DB intensive operations in parallel (not on the
> ActiveMQ thread) but in separate threads. If for some reason , the client
> is pegged doing the DB operations could this cause the client to not
> respond in a timely manner to the broker and as a result we see these
> timeout issues?
>
> thanks again!
> jaya
>
>
--
View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20654762.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire format negotiation timeout
Posted by jaya_srini <jy...@Hotmail.com>.
Thanks for the response, Steve!
Our broker is not public and the clients are all internal applications and
not internet users.
we intermittently altho frequently see this error when the client is trying
to publish a message. Our clients are both publishers and subscribers. For
every publish, the client creates a new connection, sends the message and
closes the connection. it receives the message on a separate connection.
Our clients also do DB intensive operations in parallel (not on the ActiveMQ
thread) but in separate threads. If for some reason , the client is pegged
doing the DB operations could this cause the client to not respond in a
timely manner to the broker and as a result we see these timeout issues?
thanks again!
jaya
stevec wrote:
>
> I do not know why they classify as an "ERROR". This is good for
> information purposes; it is not an error.
>
> Go ahead and telnet to your broker using your brokers port. Then do
> nothing. You will generate this error after the timeout. This error is
> caused by many different possibilities:
>
> Your client initiates a connection and then does nothing. Are you
> clients regular internet users? if so, then this is perfectly normal
> unless you are getting a number of these every few seconds. If your
> clients are your own internal applications, then you should investigate.
>
> If your broker is publically accessible and as part of normal internet
> traffic, there are people sniffing out your ports. they connect to this
> port, dont know how to respond to activemq, and they get booted off with
> the timeout.
>
> If you have a publically accessible broker you will see this "error".
>
>
> jaya_srini wrote:
>>
>> Sorry to bug about this but can someone please respond...we are using
>> ActiveMQ 5.1.0 and are seeing this error in our production environement
>> quite frequently. This is a critical issue for us right now
>>
>
>
--
View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20653626.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire format negotiation timeout
Posted by stevec <ba...@hotmail.com>.
I do not know why they classify as an "ERROR". This is good for information
purposes; it is not an error.
Go ahead and telnet to your broker using your brokers port. Then do
nothing. You will generate this error after the timeout. This error is
caused by many different possibilities:
Your client initiates a connection and then does nothing. Are you clients
regular internet users? if so, then this is perfectly normal unless you are
getting a number of these every few seconds. If your clients are your own
internal applications, then you should investigate.
If your broker is publically accessible and as part of normal internet
traffic, there are people sniffing out your ports. they connect to this
port, dont know how to respond to activemq, and they get booted off with the
timeout.
If you have a publically accessible broker you will see this "error".
jaya_srini wrote:
>
> Sorry to bug about this but can someone please respond...we are using
> ActiveMQ 5.1.0 and are seeing this error in our production environement
> quite frequently. This is a critical issue for us right now
>
--
View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20652190.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Wire format negotiation timeout
Posted by jaya_srini <jy...@Hotmail.com>.
Sorry to bug about this but can someone please respond...we are using
ActiveMQ 5.1.0 and are seeing this error in our production environement
quite frequently. This is a critical issue for us right now
I wanted to understand if this is a bug on the ActiveMQ side
(https://issues.apache.org/activemq/browse/AMQ-1473) or if there is an issue
with our usage .
If it is a client issue then what could be some scenarios that can cause
this e.g. firewall, network configuration or something else?
Wireformat negotiation timout error from the broker is usually accompanied
with this exception in the client log
Async exception with no exception listener: java.net.SocketException:
Software caused connection abort: recv failed
java.net.SocketException: Software caused connection abort: recv failed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:50)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:58)
at java.io.DataInputStream.readInt(DataInputStream.java:370)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:268)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:192)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:184)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:172)
at java.lang.Thread.run(Thread.java:619)
Any input greatly appreciated!
thanks
jaya
jaya_srini wrote:
>
> Hi
>
> can someone answer my email below?
>
> Basically
>
> What could be some possible causes of the wireformat negotiation not being
> established?
>
> Also, Is there a way to set the default timeout parameter from the
> Connection URI i.e one of the wireformat.* options?
>
> Currently we are seeing a lot of negotiation timeouts and I would like to
> understand why this happens. Could it be related to network connectivity
> issues?
>
> thank you
> jaya
>
>
>
> jaya_srini wrote:
>>
>> Thanks Joe!
>>
>> No. we only see this if I send higher than certain number of requests
>> (after about 1000 - 2000 concurrent requests)
>>
>> Couple of questions...
>>
>> What could be some possible causes of the negitiation not being
>> established?
>>
>> Also, Is there a way to set this timeout parameter from the Connection
>> URI i.e one of the wireformat.* options?
>>
>>
>>
>> ttmdev wrote:
>>>
>>> The TransportConnector is used by the broker to listen for and accept
>>> connection requests from clients and other brokers. When a connection is
>>> initially established, the connection endpoints go through a wireformat
>>> negotiation phase. This is explained on this page.
>>>
>>> http://activemq.apache.org/openwire-version-2-specification.html
>>>
>>> In your case, I suspect that the broker has sent its wireformat info
>>> object and is waiting for the other endpoint (peer) to respond, which it
>>> never does within the alloted timeout. The default timeout value is 15
>>> seconds (see
>>> http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/transport/WireFormatNegotiator.html
>>> WireFormatNegotiator.htm ).
>>>
>>> Do you see the problem with a lighter connection request load?
>>>
>>> Joe
>>>
>>>
>>>
>>> jaya_srini wrote:
>>>>
>>>> Hello
>>>>
>>>> We are using ActiveMQ 5.0 and we see these messages in the logs when
>>>> the broker is hit with multiple requests (in our case > 1000 concurrent
>>>> requests). Each request creates a new connection, sends a message to
>>>> the topic and closes the connection. There is also a durable consumer
>>>> that gets created once and receives messages asynchrounously from the
>>>> topic
>>>>
>>>> ERROR TransportConnector - Could not accept connection :
>>>> Wire format
>>>> negotiation timeout: peer did not send his wire format.
>>>> ERROR TransportConnector - Could not accept connection :
>>>> Wire format
>>>> negotiation timeout: peer did not send his wire format.
>>>>
>>>> Can someone explain what the above error message means and how this can
>>>> be resolved?
>>>>
>>>> We are using the following Connect URI
>>>>
>>>> tcp://localhost:61616?jms.useAsyncSend=true&jms.dispatchAsync=true&wireFormat.maxInactivityDuration=-1
>>>>
>>>> thank much in advance!
>>>> jaya
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20651805.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.