You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Hiram Chirino (JIRA)" <ji...@apache.org> on 2006/08/11 18:24:23 UTC
[jira] Created: (AMQ-875) TCP connector (server) will stop
accepting connection if an invalid connection is made to him.
TCP connector (server) will stop accepting connection if an invalid connection is made to him.
----------------------------------------------------------------------------------------------
Key: AMQ-875
URL: https://issues.apache.org/activemq/browse/AMQ-875
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Charles reported on the mailing list:
Hi All,
We've just had a nasty situation : our ActiveMQ Server standalone plain
vanilla TCP Transport, no persistency, no nuffink) on one of our live
installations suddenly refused to accept any new connections - no clients
could connect. All currently connected clients were fine, and messages were
being processed sent and received fine. Just no-one else could connect.
After 20 minutes, new connections were suddenly allowed.
The following exception was in our log.
2006-Aug-11 12:17:47.726 aqualive [ActiveMQ Transport Server:
tcp://blah:61616] ERROR org.apache.activemq.broker.TransportConnector -
Could not accept connection: java.net.SocketException: Connection reset by
peer: socket write error
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at
org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedO
utputStream.java:108)
at java.io.DataOutputStream.flush(DataOutputStream.java:101)
at
org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:125)
at
org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.jav
a:141)
at
org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormat
Negotiator.java:128)
at
org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiato
r.java:64)
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
at
org.apache.activemq.broker.TransportConnection.start(TransportConnection.jav
a:75)
at
org.apache.activemq.broker.TransportConnector$1.onAccept(TransportConnector.
java:136)
at
org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.
java:137)
at java.lang.Thread.run(Thread.java:534)
My interpretation of the above that something (port scanner maybe ? Our
curious IT department ?) is connecting to the listening socket, and the
TransportServer is trying to tell the connecting process what the wireformat
is - and the connection process is just sitting there, not responding,
acknlowedging, or doing anything at all - yet not closing the connection.
Therefore, the transport server is blocked, preventing anyone else
connecting. After 20 mins - which I am guessing is somekind of lowlevel
timeout, seeing as all the default AMQ timeouts seen to be of the order of 1
- 30 secs - a low level TCP exception is thrown, freeing the whole shebang
up.
I notice there is an InactivityMonitor, and looking at the code there is the
following comment
// Disable inactivity monitoring while processing a command.
Could this be the case ? That - until the wireformat has been negotiated -
there is no timeout configured ? Is there anything we can do to reduce this
timeout from 20 mins ? Or have I completed gone down the wrong track ?
This is AMQ 4.0, Win2K, JRE 1.4.2
Cheers,
Charles
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-875) TCP connector (server) will stop
accepting connection if an invalid connection is made to him.
Posted by "Charles Anthony (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-875?page=comments#action_37032 ]
Charles Anthony commented on AMQ-875:
-------------------------------------
This has just reoccured on a different client site...
> TCP connector (server) will stop accepting connection if an invalid connection is made to him.
> ----------------------------------------------------------------------------------------------
>
> Key: AMQ-875
> URL: https://issues.apache.org/activemq/browse/AMQ-875
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 4.0
> Reporter: Hiram Chirino
> Assigned To: Hiram Chirino
>
> Charles reported on the mailing list:
> Hi All,
> We've just had a nasty situation : our ActiveMQ Server standalone plain
> vanilla TCP Transport, no persistency, no nuffink) on one of our live
> installations suddenly refused to accept any new connections - no clients
> could connect. All currently connected clients were fine, and messages were
> being processed sent and received fine. Just no-one else could connect.
> After 20 minutes, new connections were suddenly allowed.
> The following exception was in our log.
> 2006-Aug-11 12:17:47.726 aqualive [ActiveMQ Transport Server:
> tcp://blah:61616] ERROR org.apache.activemq.broker.TransportConnector -
> Could not accept connection: java.net.SocketException: Connection reset by
> peer: socket write error
> java.net.SocketException: Connection reset by peer: socket write error
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedO
> utputStream.java:108)
> at java.io.DataOutputStream.flush(DataOutputStream.java:101)
> at
> org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:125)
> at
> org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.jav
> a:141)
> at
> org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormat
> Negotiator.java:128)
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiato
> r.java:64)
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52)
> at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.jav
> a:75)
> at
> org.apache.activemq.broker.TransportConnector$1.onAccept(TransportConnector.
> java:136)
> at
> org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.
> java:137)
> at java.lang.Thread.run(Thread.java:534)
> My interpretation of the above that something (port scanner maybe ? Our
> curious IT department ?) is connecting to the listening socket, and the
> TransportServer is trying to tell the connecting process what the wireformat
> is - and the connection process is just sitting there, not responding,
> acknlowedging, or doing anything at all - yet not closing the connection.
> Therefore, the transport server is blocked, preventing anyone else
> connecting. After 20 mins - which I am guessing is somekind of lowlevel
> timeout, seeing as all the default AMQ timeouts seen to be of the order of 1
> - 30 secs - a low level TCP exception is thrown, freeing the whole shebang
> up.
> I notice there is an InactivityMonitor, and looking at the code there is the
> following comment
> // Disable inactivity monitoring while processing a command.
> Could this be the case ? That - until the wireformat has been negotiated -
> there is no timeout configured ? Is there anything we can do to reduce this
> timeout from 20 mins ? Or have I completed gone down the wrong track ?
> This is AMQ 4.0, Win2K, JRE 1.4.2
> Cheers,
> Charles
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira