Change to autest When functions

[Jason Kenny <jk...@oath.com.INVALID>]

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

Re: Change to autest When functions

[Derek Dagit <de...@oath.com.INVALID>]

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 <jk...@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