In WildFly 9.0.1, incoming remote EJB invocations cause the server to leak sockets when the remoting connection is closed by the client.
The sockets are visible in netstat output for a short while in TIME_WAIT status and then they go away, but the sockets can be seen in lsof output for the server process. This does not happen on every connection close, but it still happens much too often.
The leak occurs when remoting is configured using <connector> and when configured using <http-connector>. In both configurations I had SSL enabled, I have not tested without SSL.
More detailed description:
- EJB client application is short lived process that does an EJB invocation and then exists.
- Network connection over localhost
- Before exit the connection is closed using EJBClientContext.getCurrent.close. Whether the close is done or not has no effect. (By the way, a separate issue: If the close is not done, the shutdown hook installed by the ejb client code sometimes dead locks and the process does not exit)
- Result: netstat ALWAYS shows at least one end of the connection in TIME_WAIT status (it varies which end stays in TIME_WAIT), sometimes both ends.
- Not all invocations, but many invocations produce this in lsof output of the server process:
|java||14598 huuskoa 569u||sock||0,8||0t0 2733585 protocol: TCP|
- Older linux kernel shows this as "can't identify protocol"
- I also watched the traffic with tcpdump, and shutdown process varies almost on every connection
- Sometimes both ends send FIN packet
- Sometimes neither end sends FIN packet
- Sometimes only end sends FIN
- I tried to configure the client to use CLOSE_ABORT setting; as a result the client sometimes but very rarely sends RST
Remoting is configured in wildfly like this:
<http-connector name="http-remoting-connector" connector-ref="https1"
EJB client context properties:
Java version 8u60.
I tried to replace jboss-remoting in wildfly with JBoss Remoting 4.0.14.Final, but this did not help.
Attached are two org.jboss.remoting TRACE logs: the first case did not leak a socket, the second case did leak.
jboss-remoting-leak.txt.zip 4.1 KB