activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik (JIRA)" <>
Subject [jira] Commented: (AMQ-1860) soTimeout transport property- Incorrect documentation (or code, you pick)
Date Fri, 18 Jul 2008 19:05:00 GMT


Filip Hanik commented on AMQ-1860:

As a side note, and not relevant to this issue, let me explain why soTimeout=0 is a bad default

Lets say you have a connection between a consumer and the AMQ server, that connections gets

When a socket is closed, it doesn't really mean its closed - this is explained in:

On the server the following will happen

yy.yy.yy.yy.61616    xx.xx.xx.xx.44674    49152      0 49330      0 CLOSE_WAIT

And inside of the AMQ you'll see the following stack trace
"ActiveMQ Transport: tcp:///xx.xx.xx.xx:44674" daemon prio=4 tid=0x002ebc88 nid=0x2a runnable
        at Method)
        at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(
        at org.apache.activemq.transport.tcp.TcpTransport.oneway(
        at org.apache.activemq.transport.InactivityMonitor.oneway(
        - locked <0xd8775fc0> (a org.apache.activemq.transport.InactivityMonitor$2)
        at org.apache.activemq.transport.TransportFilter.oneway(
        at org.apache.activemq.transport.WireFormatNegotiator.oneway(
        at org.apache.activemq.transport.MutexTransport.oneway(
        - locked <0xd8775da8> (a java.lang.Object)

please remember, the client is no longer connected, and is no longer reading data. The server
now has a CLOSE_WAIT connection and a thread that is stuck in this state.
The socketWrite0 will only return after a TCP packets has moved on the connection (which it
wont since the client is no longer present) or until it times out (which it wont since soTimeout
is 0)

As you can see this thread is also holding a bunch of locks, some of these interfer with other
server threads, causing the system to display systems of being hung. The only work around
ar this point is to restart the AMQ server.

Hope this makes sense. My recommendation would be to have a >0 soTimeout value as default,
(and the property name be documented properly of course:) )


> soTimeout transport property- Incorrect documentation (or code, you pick)
> -------------------------------------------------------------------------
>                 Key: AMQ-1860
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker, Documentation
>    Affects Versions: 5.0.0, 5.1.0
>         Environment: All
>            Reporter: Filip Hanik
> The documentation for TCP transport, shows soTimeout, connectionTimeout and socketBufferSize
as properties without a prefix.
> The code in doesn't have the support for these properties.
> hence setting a URL to tcp:// does nothing, and defaults
to soTimeout=0 (which is a bad value due to how sockets get closed, and can cause the system
to hang on  a socketWrite call, causing the rest of the server to hang, but I can explain
that on the dev lists for those interested)
> Bug description: Transport properties are incorrectly document or implemented
> There are two solutions to this bug:
> 1. The preferred, would be to fix the documentation
> the mentioned options will work if they are prefixed with "transport."
> so the URL would be 
> tcp://
> 2. Add the properties with their getters/setters into and then
during the handleSocket method add them to the options map
> Please note, this bug refers to the soTimeout setting on the socket that gets created
on the server when a producer/consumer connects in using TCP
> best
> Filip

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message