checkssl | checks ssl certs for a set of domains | TLS library

So it seems I found the source of the error. To me, it looks like a classic concurrency issue. I fixed it by changing a single line of code in vertx-core version 2.1.6, changing a write operation to writeAndFlush. The fix is probably bypassing the intentions of the original author and will result in a few un-necessary flush operations on the netty channel.

This is what I think is happening. To follow my reasoning in the code, have a look at org.vertx.java.core.net.impl.ConnectionBase in 2.1.6. There are two flags involved: read and needsFlush. I am assuming here that there are two threads accessing the channel concurrently.

1. Vert.x HttpServer receives a http request, opens a Netty channel and successfully reads the entire request. The handler is put in READ mode while reading, then back into WRITE mode, flushing the write buffer: read = false, needsFlush = false.
2. Before Vertx HttpServer starts to write the response to the first request, it receives another http request and starts to read again. This puts the handler in READ mode: read = true
3. The http handler now wants to write the response to the first request, but since read = true, the writing will begin by setting needsFlush = true, and prepares to queue the response.
4. However, before any bytes are queued, the reading thread takes over again, finishes reading the second request, thus setting read = false, flushes the (empty) write buffer (since needsFlush = true) and sets needsFlush = false.
5. Now the writing thread picks up again. Since it is already past checking the read flag, it just writes the bytes to the channel without flushing. The channel will now never be flushed, since no more endReadAndFlush will occur.

To fix this problem, I updated