activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Nigro (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers
Date Mon, 16 Apr 2018 12:35:00 GMT

     [ https://issues.apache.org/jira/browse/ARTEMIS-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Francesco Nigro updated ARTEMIS-1811:
-------------------------------------
    Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of direct ByteBuffers
performed internally by NIO.

Those buffers are pooled until certain size limit (ie jdk.nio.maxCachedBufferSize, as shown https://bugs.openjdk.java.net/browse/JDK-8147468) and
when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances and potential
OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that provide the right
API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of direct ByteBuffers
performed internally by NIO.

Those buffers are pooled until certain size limit (ie [https://bugs.openjdk.java.net/browse/JDK-8147468|jdk.nio.maxCachedBufferSize]) and
when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances and potential
OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that provide the right
API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1811
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 2.5.0
>            Reporter: Francesco Nigro
>            Assignee: Francesco Nigro
>            Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of direct ByteBuffers
performed internally by NIO.
> Those buffers are pooled until certain size limit (ie jdk.nio.maxCachedBufferSize, as
shown https://bugs.openjdk.java.net/browse/JDK-8147468) and when not pooled are cleaned
at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances and potential
OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that provide the
right API to append byte[] without creating additional native copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message