Up until 2.4.10, MaxScale would, when closing a connection to a backend, unconditionally send a COM_QUIT. That was erroneous most of the time, because if the client behaves properly it would end its connection by sending a COM_QUIT, which would then be sent to the backend. That is, MaxScale would in general send two {{COM_QUIT}}s at connection closing time.

In 2.4.11 that was changed so that MaxScale would at connection closing time explicitly send a COM_QUIT only if the client hadn't send one. That is the correct thing to do.

However, then it was reported that 2.4.11 used a lot more CPU than 2.4.10 and as there in the log of 2.4.11 were numerous 99, Cannot assign requested address errors, the assumption is that that is the real problem and the increased CPU usage is only a side-effect.

Running a tight CONNECT; SELECT 1; DISCONNECT loop by 20 threads in parallel causes the error to appear (although only in a rather artificial setup), which also leads to the number of iterations performed during a time period to drop dramatically, compared to 2.4.10.

There does not seem to be anything wrong in the protocol handling code of MaxScale. A peculiar fact is that if at connection closing time, anything extra (a single byte) is written to the socket before it is closed, then the behaviour disappears. No reasonable explanation for that has been found.

Further testing has revealed that a second write is actually not necessary. Everything will also work if, when the COM_QUIT is sent, we send 1 more byte than the size of the actual COM_QUIT packet, that is, instead of sending the 5 bytes of COM_QUIT we send 6 bytes with the last byte being arbitrary data.