Julien,
Having the QueuedThreadPool configured so that it may reject jobs is not recommended and is likely to result in problems. More over, having such a small threadpool (4 threads!) and a small queue (also 4) is going to mean that only moderately low load is required for jobs to be discarded.
Having said that, we should not leak memory. However in this case, if an task that would have destroyed an endpoint is lost, then the endpoint will not be destroyed. We can't destroy it on rejection as that kind of defeats the purpose of doing it as a task it in the first place. The EndPoint will eventually timeout, but that may just queue another destroy event which could be rejected, or maybe even the timeout task itself is being rejected.
In an asynchronous server, if you randomly reject tasks, then some async lifecycles will never complete and a leak will result. I highly recommend having an infinite job queue and using other means to restrict the size (limite connections or requests rather than tasks). At the very least, have a limited job queue that blocks when full rather than rejects.
However, please raise an issue on github for this, as we should at least look at a reproduction and see if there is anything more we can do with that rejected execution to be more robust.
regards
