Memory / socket leak when closing a WebSocket in case receive setter is not explicitly overridden

Undertow does not release memory associated with WebSocket connection after calling WebSockets.sendClose if receive setter is not explicitly overridden by the client code. Same happens if WebSocketChannel.sendClose is used. It leads to socket / file descriptor leak which in turn causes severe hiccup later on (hit in production several times and can be easily observed in a profiler).

Attached project demonstrates this scenario. It leads to a leak with close listeners not being called / strong references to WebSocket-related objects being held / sockets and respective file descriptors being kept open (even though the client is already disconnected).

It is very well understood that there is an easy fix to this by having receive setter always explicitly overridden (as Undertow example demonstrates), but:

• IMO this is an unacceptable default. As a client developer I would expect receive setter to be there and reacting to ping / ping and close events at least.
• It is not well documented.
• It is easy to miss and then very hard to find out what is wrong, especially when code evolves and becomes more complex.

Moreover, server won't react on client's call to disconnect if receive setter is not overridden.

AFAIU this is relevant for all versions of Undertow.