Yes, there is evidently a race between the microserver binding the port and the server actually spinning up.
As far as the API we have to use, I think it would be good to be very specific in our naming. I would replace PortReady with something like CanTcpConnect, because that is what the code does. I would replace PortOpen with something like IsPortBound, likewise because this is what the code checks for. I am experimenting with adding a basic health check, such that whenever any microserver is created with MakeOriginServer, it will proceed as soon as a request is successfully served. Hopefully this will cut down on spurious test errors. > For example, it might be useful to send some message to ATS to see > if the cache is loaded, or some other state, before we start the "real" > test. > > Any thoughts? It would be nice to be able to configure port '0', and let the OS choose from among its ephemeral ports to bind for the traffic server. These ports could be a part of the state that is communicated back. This way we could eliminate another race between identifying available ports and binding to them. On Wed, Mar 28, 2018 at 8:24 PM, Jason Kenny <jke...@oath.com.invalid> wrote: > Hi all, > > Derek pointed out an issue he has found in When.PortOpen(...) function that > he found is causing issues with some tests. The issue is that I made a > change to PortOpen() to check for the state that the given port is open, > via using netstat like logic. The previous revision of the code was to open > a Socket on that port. The change was made as opening a port sends data to > make sure we have a something on the other side that is ready to listen. > The new code only checks a state that the something has the port. That > something may still not be ready to do anything. This leads to the issue > Derek found, which is in short a race in which the microserver has open the > port, but is not in a state to process anything yet. > > As I understand it the old logic does not have this race condition on > startup, given that the server has to send data to establish the > connection. I would like to propose adding a When.PortReady(...) Api that > does the old logic of making a socket on the given port. I believe this > should solve the problem. However, I would like to ask if anyone see a > problem with this, and if we should add some other API for this, such as an > API that opens the port and sends some data to make sure we have some state > ready. For example, it might be useful to send some message to ATS to see > if the cache is loaded, or some other state, before we start the "real" > test. > > Any thoughts? > > -Jason > -- Derek
