Skip to main content
Inspiring
June 9, 2025
Answered

Too many established TCP ports

  • June 9, 2025
  • 1 reply
  • 5213 views

I have a server running 7 instances of CF (6 sites plus root instance).  If I run a NetStat, I generally see about 1800 ports as "ESTABLISHED"  (see below for a sample).  Why so many ports connected to itself?

 

Ultimately what happens is the server just kind of dies because it can't establish any more sockets.  I don't think it's "port exhaustion" because I see the total number of connections staying around that 1800 mark, and there aren't piles of TIME_WAIT entries.

 

What I THINK is happening, is, as this issue is cycling through ports, it gets to a 65535 ceiling and is not looping back to lower ports, thus killing connectivity.

 

Any thoughts on what's going on here?

 

TCP 127.0.0.1:49890 site01-wf:49891 ESTABLISHED
TCP 127.0.0.1:49891 site01-wf:49890 ESTABLISHED
TCP 127.0.0.1:49892 site01-wf:49893 ESTABLISHED
TCP 127.0.0.1:49893 site01-wf:49892 ESTABLISHED
TCP 127.0.0.1:49894 site01-wf:49895 ESTABLISHED
TCP 127.0.0.1:49895 site01-wf:49894 ESTABLISHED
TCP 127.0.0.1:49896 site01-wf:49897 ESTABLISHED
TCP 127.0.0.1:49897 site01-wf:49896 ESTABLISHED
TCP 127.0.0.1:49898 site01-wf:49899 ESTABLISHED
TCP 127.0.0.1:49899 site01-wf:49898 ESTABLISHED
TCP 127.0.0.1:49900 site01-wf:49901 ESTABLISHED
TCP 127.0.0.1:49901 site01-wf:49900 ESTABLISHED

    Correct answer RockerNJ

    Very interesting to hear. Looking forward to further news as it becomes available. 


    Just a followup for you guys since you've all been awesome with helping.  Updating these settings seems to have fixed the problem (at least so far).  No crashes since making the update!

     

    netsh int ipv4 set dynamicport tcp start=32767 num=32768

    netsh int ipv6 set dynamicport tcp start=32767 num=32768

     

    and a registry edit:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    TcpTimedWaitDelay

    REG_DWORD

    Value: 30

    1 reply

    BKBK
    Community Expert
    Community Expert
    June 10, 2025

    First of all, what is your:

    • Operating System?
    • ColdFusion version and update level?
    RockerNJAuthor
    Inspiring
    June 10, 2025

    Windows Server 2022 Datacenter

    Coldfusion 2021 + Hotfix20

    BKBK
    Community Expert
    Community Expert
    June 13, 2025

    Hi @RockerNJ and @Dave Watts , to respond to your last posts, I do understand your point of view. I initially had the same thoughts myself. In fact, I have to clarify one thing. Like you, I am at a loss what the exact cause of the issue is.

     

    I proposed HTTP as a diagnostic suggestion. But I didn't leave it there.

     

    In addition, I offered further diagnostic proposals that would either back up the HTTP idea or refute it. For example,

    • Using a connection-close header;
    • Checking what the ColdFusion logs say about the issue;
    • Examining the contents of http.log (Is there a recurrent log-line?) and its size (for example, has ColdFusion rotated or archived the file?). 

     

    I shall now offer yet another diagnostic proposal. In every CFHTTP request, such as

    <CFHTTP URL="http://#cgi.server_name#/workflow_manager/act_check_workflow_queue.cfm" TIMEOUT="1">

    replace every occurrence of #cgi.server_name# with the actual domain name, for example, my.domain.com. Does that help?


    @RockerNJ , Did you try out my last suggestions? Did they help?

    Here are yet more thoughts on the issue. 

     

    You and Dave supposed that, if the traffic isn’t over 80 or 443, then these are unlikely to be HTTP requests. However, when I looked further into the issue, I found that internal HTTP communication within ColdFusion may use high-numbered dynamic ports.

    So, here are 3 reasons why It is still likely the issue is caused by HTTP/CFHTTP connections:

     

    1.  ColdFusion and the underlying (Tomcat/Jetty) servlet container may use ports different from 80 and 443.
    Since you are running multiple CF instances, each one may be configured to listen on its own custom random ephemeral port. So a cfhttp call from one CF instance to another will be using these random ports.

     

    2.  The Netstat result shows that the TCP socket pairs are bidirectional (A <==> B) and ESTABLISHED.
    The pattern:

    TCP 127.0.0.1:51140 127.0.0.1:51139 ESTABLISHED
    TCP 127.0.0.1:51139 127.0.0.1:51140 ESTABLISHED

    is neither a one-way connection nor a connection from a background protocol such as RMI. It is bidirectional, exactly what you would expect from an internal client/server TCP pair. This strongly suggests application-level communication, hence HTTP.

     

    3.  ColdFusion itself (coldfusion.exe) is the process opening both ends.
    This tells us that ColdFusion is both the client and the server. This is exactly how an internal cfhttp call to 127.0.0.1:{port_number} works: one thread binds a client socket, another listens on the HTTP server socket.