[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Description:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!2020-11-10-112753_563x276_scrot.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
that is our patched library:
[^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
was:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
that is our patched library:
[^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: 2020-11-10-112753_563x276_scrot.png, api_src_main_java_org_xnio_ByteBufferSlicePool.java, image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !2020-11-10-112753_563x276_scrot.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
> that is our patched library:
> [^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Attachment: 2020-11-10-112753_563x276_scrot.png
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: 2020-11-10-112753_563x276_scrot.png, api_src_main_java_org_xnio_ByteBufferSlicePool.java, image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
> that is our patched library:
> [^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Description:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
was:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is where there no problem with OOM.
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14189) The RunAs annotation doesn't work in EJBs with Elytron
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14189?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-14189:
------------------------------------
Fix Version/s: (was: 21.0.2.Final)
> The RunAs annotation doesn't work in EJBs with Elytron
> ------------------------------------------------------
>
> Key: WFLY-14189
> URL: https://issues.redhat.com/browse/WFLY-14189
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 21.0.0.Final
> Reporter: Alessandro Moscatelli
> Priority: Major
> Labels: ejb, elytron, regression, runas, security, startup
> Attachments: standalone-full-ha.new.xml, test.zip
>
>
> Role is not correctly assigned when using @RunAs annotation and Elytron Security Domain. Everything works correctly with legacy picketbox Security Domain.
> Wildfly is configured to use default "other" application-security-domain, also using default security domain ApplicationDomain.
> This exception is rised when deploying the application.
> Caused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowedCaused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowed at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.security.JaccInterceptor.hasPermission(JaccInterceptor.java:120)
> Test/Sample project: [^test.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Attachment: api_src_main_java_org_xnio_ByteBufferSlicePool.java
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: api_src_main_java_org_xnio_ByteBufferSlicePool.java, image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Description:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
that is our patched library:
[^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
was:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: api_src_main_java_org_xnio_ByteBufferSlicePool.java, image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
> that is our patched library:
> [^api_src_main_java_org_xnio_ByteBufferSlicePool.java]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Description:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
was:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code:java}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code:java}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Description:
Wildfly.19.0.1.Final standalone
We'd found an issue with direct memory buffer leaking on one from our servers.
There is rest api application allocated there.
it provides hugh data on some requests.
As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
You can see it on graphs with memory. Red line means direct memory buffer.
At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
There are some drops of redline to zero, but there were restarts of wildfly.
As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
{code}
2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
!image_2020_10_30T09_55_47_082Z.png|thumbnail!
When something needs memory it allocates and save this memory to directBuffers(that was removed)
Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
So, after removing variable directBuffers we'd found a "method".
We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is where there no problem with OOM.
was:!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> Wildfly.19.0.1.Final standalone
> We'd found an issue with direct memory buffer leaking on one from our servers.
> There is rest api application allocated there.
> it provides hugh data on some requests.
> As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer.
> !Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
> Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer.
> You can see it on graphs with memory. Red line means direct memory buffer.
> At first time it takes as much as it can, but after changing session lifetime we faced the same problem.
> There are some drops of redline to zero, but there were restarts of wildfly.
> As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases.
> Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21)
> {code}
> 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149)
> at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
> !image_2020_10_30T09_55_47_082Z.png|thumbnail!
> When something needs memory it allocates and save this memory to directBuffers(that was removed)
> Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it
> Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate.
> So, after removing variable directBuffers we'd found a "method".
> We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it.
> You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is where there no problem with OOM.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ]
Mike Zhary updated WFLY-14233:
------------------------------
Attachment: image_2020_10_30T09_55_47_082Z.png
> Undertow xnio direct memory buffer leaking
> ------------------------------------------
>
> Key: WFLY-14233
> URL: https://issues.redhat.com/browse/WFLY-14233
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Reporter: Mike Zhary
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
>
>
> !Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking
by Mike Zhary (Jira)
Mike Zhary created WFLY-14233:
---------------------------------
Summary: Undertow xnio direct memory buffer leaking
Key: WFLY-14233
URL: https://issues.redhat.com/browse/WFLY-14233
Project: WildFly
Issue Type: Bug
Components: IO, Web (Undertow)
Reporter: Mike Zhary
Assignee: Flavia Rainone
Attachments: Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png
!Снимок экрана 2020-12-16 в 15.33.53.png!!Снимок экрана 2020-12-16 в 15.34.20.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0