Finding a port in a storm: Or how to get a consistent build experience
time to read 4 min | 657 words

RavenDB is a server product, as such, we are obvious going to have to talk over the network. That is great, except that it means we need a system wide resource, a TCP port. And that isn’t so great, because it turn out that there are a lot of things that can try to grab a port and use it.

And I don’t speak about things like Skype taking over port 80. I’m talking about the use of dynamic or ephemeral ports. That means that during the build, we can have something (for example, Chrome, or DropBox, or anything that uses the web) make a call and suddenly that port is busy and you can’t bind to it.

The default ports we use for tests are in the 8070 – 8090 range, but we have had consistent build failures because something is taking the ports. Finally I took the time to investigate, and I discovered that:

   1: C:\Work\ravendb-3.0 [master]> netsh int ipv4 show dynamicport tcp
   2:  
   3: Protocol tcp Dynamic Port Range
   4: ---------------------------------
   5: Start Port      : 1025
   6: Number of Ports : 64510

So, on the two machines I tested this on, we had the dynamic port range cover everything from port 1025 and up. This sucks. And probably explains the issue. This is how we fixed it (I hope):

   1: netsh int ipv4 set dynamicportrange tcp startport=10000 numberofports=55535

Basically, everything below port 10,000 is free for us to use. And yes, this post is here mostly so I’ll not have to remember it in the future.

Tweet Share Share 5 comments
Tags: