API connections stuck in CLOSE_WAIT when sending invalid HTTP request

When trying to do a primitive connectivity test to the REST API with

echo > /dev/tcp/127.0.0.1/8999

the maxscale process will never close its side of the TCP connection so that a socket will be lost in CLOSE_WAIT status forever.

When running the check repeatedly there will eventually be no client sockets left as they all get stuck in CLOSE_WAIT.

When preventing echo from sending a newline character with echo -n, or when sending a valid simple HTTP request with

echo "GET / HTTP/1.1\nHost: localhost\n\n" > /dev/tcp/127.0.0.1/8999

no socket in CLOSE_WAIT is left behind.

So it looks as if things get stuck if some text of more than zero bytes is sent, but does not form a valid / complete HTTP request ...

Implemented Solution

Added admin_timeout with a default value of 5 minutes. This is only for the HTTP request processing so once the request has been processed, the timeout does not apply to the actual operation itself inside MaxScale. This should be a fully backwards compatible change with only the erroneus behavior solved. The timeout has to be adjustable in order to make it possible to have tighter timeouts in cases where e.g. TCP health check pings leave the connection open for some reason.