Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

  • Comments
  • Connections on remoting port (4447) never closed on server when client crashes or network is interrupted

    Posted on

    We run a rich client using ejb-client/remoting to access EJB and JMS on JBoss EAP 6.3.3

    When a client starts, 2 tcp/ip connections are opened. netstat (on windows) listens the connections:

      TCP    172.21.15.24:4447      172.21.15.163:49421    HERGESTELLT
      TCP    172.21.15.24:4447      172.21.15.163:49886    HERGESTELLT
      TCP    172.21.15.24:4447      172.21.15.163:49887    HERGESTELLT
      TCP    172.21.15.24:4447      172.21.15.163:49939    HERGESTELLT
      TCP    172.21.15.24:4447      172.21.15.163:49941    HERGESTELLT
    

    When the client crashes (or the network is interrupted e.g. unplug RJ45 ), the ports on the server are not closed. Even if you run netstat after 2 days, the connections are
    still 'established'. If the user now restarts the client, new connections are opened. The old ones are still in the list.

    If the client stops in normal case (no crash, not network interruption), you see the following lines in the server log:

    14:24:21,001 TRACE [org.jboss.remoting.remote] (Remoting "zugnb-als8-01" read-1) Closed inbound channel on Connection handler for Remoting connection 27b9186e to /172.21.15.163:56099
    14:24:21,001 TRACE [org.jboss.remoting.remote.connection] (Remoting "zugnb-als8-01" read-1) Shut down writes on channel
    

    You don't see anything like this if the client terminates abnormaly. That means the channel is still open. This corresponds to what I see in netstat.

    HornetQ detects such 'dead' connections and closes them, but remoting not.

    If this happens too often, JBoss server becomes slow, instabel and at the end it does not accept any new connections and clients can not login anymore. The only way to recover is restarting JBoss server.

    We also tried to set KEEP_ALIVE property in the remoting subsystem, but that doesn't help.

                
                    
                        
                        
                        
                        
                    
                
    

    Any known solution or idea? Thanks in advance.

    by

    points

    Responses

    Red Hat

    Quick Links

    Help

    Site Info

    Related Sites

    © 2025 Red Hat, Inc.