Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Question regarding Websocket and MappedByteBufferPool behavior

Hi,

On Tue, Jul 30, 2019 at 11:21 AM Ofir Prizat <ofir.prizat@xxxxxxxxx> wrote:
>
> Hi,
>
> I wanted to ask about how MappedByteBufferPool behaves when held by WebSocketClient.
>
> From what I can see, Jetty is instantiating a MappedByteBufferPool which serves as a buffer that is used by all WebSocketClient threads.

It does not serve as a "buffer" but as a "pool".

> Using heapdump/threaddump analysis I can see that websocket messages that are sent from clients (inbound messages) are stored in that buffer. I can also see that there are multiple threads in RUNNABLE state, which point to that buffer. However, when those clients disconnect the websocket, I can see those WebScocket threads change their state to TIMED_WAITING (All but onem which stays RUNNABLE) but the buffer does not clear itself up nor gets cleared by GC, because there is still a single thread pointing to it, and eventually causing our application to run out of memory.
>

It is normal that WebSocket client references MappedByteBufferPool so
that even when your system is idle, they stay alive.
They are long lived components,  and until you stop the WebSocket
client (or shut down the JVM), you will have them around.

I have doubts that is the MappedByteBufferPool that is causing your
application to run out of memory.
It's a pool and we reuse the ByteBuffers it contains and don't
allocate more than it's needed.

Your screenshots do not show any evidence of your memory problems, so
it's difficult to say, but I would first double check your application
for memory leaks.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top