[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316739=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316739 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 23/Sep/19 15:00 Start Date: 23/Sep/19 15:00 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316739) Time Spent: 3h 50m (was: 3h 40m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3h 50m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316528=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316528 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 23/Sep/19 08:26 Start Date: 23/Sep/19 08:26 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" differently the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). This has been shown using `async-profiler` on a benchmark code here: https://github.com/netty/netty/pull/9591#issuecomment-534000527 ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. The overhead of file reading using `RandomAccessFile` and `byte[]` vs `FileChannel` and direct `ByteBuffer` is variable, but using the benchmark I've used on Netty [here](https://github.com/netty/netty/pull/9591#issuecomment-534002621) has given this result: ``` Benchmark (chunkSize)(fileName) (fileSize) (ioSize) Mode Cnt Score Error Units ChunkedFileBenchmark.readFullyFile 32768 /tmp/raf.tmp 10485760 32768 avgt4 2153.527 ± 715.641 us/op ChunkedFileBenchmark.readFullyFileWithNio32768 /tmp/raf.tmp 10485760 32768 avgt4 1775.999 ± 831.715 us/op ``` That means about a 25% perf difference while using super-fast disks and I assume to be the same on write side. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316528) Time Spent: 3h 40m (was: 3.5h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3h 40m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316526=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316526 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 23/Sep/19 08:24 Start Date: 23/Sep/19 08:24 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" differently the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). This has been shown using `async-profiler` on a benchmark code here: https://github.com/netty/netty/pull/9591#issuecomment-534000527 ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. The overhead of using `RandomAccessFile` and `byte[]` vs `FileChannel` and direct `ByteBuffer` is variable, but using the benchmark I've used on Netty here has given this result: ``` Benchmark (chunkSize)(fileName) (fileSize) (ioSize) Mode Cnt Score Error Units ChunkedFileBenchmark.readFullyFile 32768 /tmp/raf.tmp 10485760 32768 avgt4 2153.527 ± 715.641 us/op ChunkedFileBenchmark.readFullyFileWithNio32768 /tmp/raf.tmp 10485760 32768 avgt4 1775.999 ± 831.715 us/op ``` That means about a 25% perf difference while using super-fast disks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316526) Time Spent: 3.5h (was: 3h 20m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3.5h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316518=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316518 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 23/Sep/19 08:16 Start Date: 23/Sep/19 08:16 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" differently the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). This has been shown using `async-profiler` on a benchmark code here: https://github.com/netty/netty/pull/9591#issuecomment-534000527 ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316518) Time Spent: 3h 20m (was: 3h 10m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3h 20m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316331=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316331 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 22/Sep/19 21:18 Start Date: 22/Sep/19 21:18 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" differently the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316331) Time Spent: 3h 10m (was: 3h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3h 10m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316309=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316309 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 22/Sep/19 18:39 Start Date: 22/Sep/19 18:39 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316309) Time Spent: 3h (was: 2h 50m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 3h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316308=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316308 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 22/Sep/19 18:39 Start Date: 22/Sep/19 18:39 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print over head of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316308) Time Spent: 2h 50m (was: 2h 40m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 2h 50m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 leaking native copies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316229=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316229 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 22/Sep/19 08:18 Start Date: 22/Sep/19 08:18 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is <= `BUF_SIZE` (ie 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because this change would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) I've added https://github.com/apache/activemq-artemis/pull/2844/commits/453c9796a486e6b9289e8cc8aa61e1ebcf41fd9f trying to mitigate the effects of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316229) Time Spent: 2h 40m (was: 2.5h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 2h 40m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[
https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316135=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316135
]
ASF GitHub Bot logged work on ARTEMIS-1811:
---
Author: ASF GitHub Bot
Created on: 21/Sep/19 13:06
Start Date: 21/Sep/19 13:06
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #2844: ARTEMIS-1811
NIO Seq File should use RandomAccessFile with heap buffers
URL: https://github.com/apache/activemq-artemis/pull/2844#discussion_r326859418
##
File path:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/nio/NIOSequentialFile.java
##
@@ -173,6 +173,40 @@ public int read(final ByteBuffer bytes) throws Exception {
return read(bytes, null);
}
+ //On *nix platform is the size by which RandomAccessFile write/read are
performed using a
+ //stack-allocated copy of the java byte[]
Review comment:
I've verified that is a the same behaviour for Windows: it is in the shared
JNI code by any OSs
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 316135)
Time Spent: 2.5h (was: 2h 20m)
> NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
> ---
>
> 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
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> JournalStorageManager::addBytesToLargeMessage and
> LargeServerMessageImpl::DecodingContext::encode are 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 on
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right
> after the write succeed.
> If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are
> always pooled regardless of the size, leading to OOM issues on high load of
> variable sized writes due to the amount of direct memory allocated and not
> released/late released.
> 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
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[
https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316075=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316075
]
ASF GitHub Bot logged work on ARTEMIS-1811:
---
Author: ASF GitHub Bot
Created on: 21/Sep/19 06:35
Start Date: 21/Sep/19 06:35
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #2844: ARTEMIS-1811
NIO Seq File should use RandomAccessFile with heap buffers
URL: https://github.com/apache/activemq-artemis/pull/2844#discussion_r326849697
##
File path:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/nio/NIOSequentialFile.java
##
@@ -173,6 +173,40 @@ public int read(final ByteBuffer bytes) throws Exception {
return read(bytes, null);
}
+ //On *nix platform is the size by which RandomAccessFile write/read are
performed using a
+ //stack-allocated copy of the java byte[]
Review comment:
This was just a POC commit to mitigate the issue , but we can discuss on the
comments about it :)
Thanks to looking at it
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 316075)
Time Spent: 2h 20m (was: 2h 10m)
> NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
> ---
>
> 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
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> JournalStorageManager::addBytesToLargeMessage and
> LargeServerMessageImpl::DecodingContext::encode are 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 on
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right
> after the write succeed.
> If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are
> always pooled regardless of the size, leading to OOM issues on high load of
> variable sized writes due to the amount of direct memory allocated and not
> released/late released.
> 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
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[
https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316068=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316068
]
ASF GitHub Bot logged work on ARTEMIS-1811:
---
Author: ASF GitHub Bot
Created on: 21/Sep/19 06:10
Start Date: 21/Sep/19 06:10
Worklog Time Spent: 10m
Work Description: michaelandrepearce commented on pull request #2844:
ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers
URL: https://github.com/apache/activemq-artemis/pull/2844#discussion_r326849133
##
File path:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/nio/NIOSequentialFile.java
##
@@ -173,6 +173,40 @@ public int read(final ByteBuffer bytes) throws Exception {
return read(bytes, null);
}
+ //On *nix platform is the size by which RandomAccessFile write/read are
performed using a
+ //stack-allocated copy of the java byte[]
Review comment:
And what about windows
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 316068)
Time Spent: 2h 10m (was: 2h)
> NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
> ---
>
> 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
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> JournalStorageManager::addBytesToLargeMessage and
> LargeServerMessageImpl::DecodingContext::encode are 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 on
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right
> after the write succeed.
> If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are
> always pooled regardless of the size, leading to OOM issues on high load of
> variable sized writes due to the amount of direct memory allocated and not
> released/late released.
> 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
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316065 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 05:43 Start Date: 21/Sep/19 05:43 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because this change would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) I've added https://github.com/apache/activemq-artemis/pull/2844/commits/453c9796a486e6b9289e8cc8aa61e1ebcf41fd9f trying to mitigate the effects of it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316065) Time Spent: 2h (was: 1h 50m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 2h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316062=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316062 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 05:00 Start Date: 21/Sep/19 05:00 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because this change would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316062) Time Spent: 1h 50m (was: 1h 40m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1h 50m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316061=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316061 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 05:00 Start Date: 21/Sep/19 05:00 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if java byte[] length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because this change would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316061) Time Spent: 1h 40m (was: 1.5h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1h 40m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316059=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316059 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:54 Start Date: 21/Sep/19 04:54 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because this change would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316059) Time Spent: 1.5h (was: 1h 20m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1.5h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316056=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316056 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:53 Start Date: 21/Sep/19 04:53 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cose of the syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because while providing this change it would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316056) Time Spent: 1h (was: 50m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316057=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316057 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:53 Start Date: 21/Sep/19 04:53 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because while providing this change it would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316057) Time Spent: 1h 10m (was: 1h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1h 10m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316058=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316058 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:53 Start Date: 21/Sep/19 04:53 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes/reads the perf hit is not very high because copy java byte[]<->stack allocated native byte[] copy is cheap if compared to the cost of the write/read syscall and won't impact scalability of the native allocator, because malloc/free isn't used. I'm worried, because while providing this change it would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316058) Time Spent: 1h 20m (was: 1h 10m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 1h 20m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316055=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316055 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:51 Start Date: 21/Sep/19 04:51 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 @wy96f @clebertsuconic Just for completeness that's what would change: - [Java_java_io_RandomAccessFile_writeBytes->writeBytes](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L85) - [writeBytes->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L189) by using a stack buffer if write/read length is < `BUF_SIZE` (=== 8192 bytes) or with a fresh new buffer allocated using malloc/free: in both cases GetByteArrayRegion/SetByteArrayRegion are used to perform a copy from/to the provided java `byte[]` - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) I see that this PR has few advantages vs https://github.com/apache/activemq-artemis/pull/2832: - it is simpler/less impactfull on artemis code base - although copies always happen, no leaks can happen I see that for small writes the perf hit is not very high because copy from/to java byte[] from the stack allocated native byte[] is cheap and the native byte[] used is stack allocated, so won't impact scalability of the native allocator. I'm worried, because while providing this change it would enable a non-transparent handling of large writes/reads on JNI that could silently kill performance due to `malloc/free` + the large copy: that's exactly our use case for OpenWire and AMQP (until we'll get streaming of large messages in) and sadly it would affect CORE too, given that CORE writes/reads in 100KB sized chunks, that's > `BUF_SIZE` (ie 8192 bytes). PLEASE DO NOT MERGE: I would like to discuss with you about it :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316055) Time Spent: 50m (was: 40m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 50m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=316050=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316050 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 21/Sep/19 04:27 Start Date: 21/Sep/19 04:27 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 Just for completeness that's what would change (ie no additional copies with heap buffers anymore): - [RandomAccessFile_write0->writeSingle](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L79) - [writeSingle->IO_Write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L138) - [IO_Write === handleWrite](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71) - [handleWrite->write](https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 316050) Time Spent: 40m (was: 0.5h) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 40m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=315745=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315745 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 20/Sep/19 15:42 Start Date: 20/Sep/19 15:42 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533606931 Just for completeness that's what would change (ie no additional copies with heap buffers anymore): - https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/RandomAccessFile.c#L79 - https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/native/java/io/io_util.c#L138 - https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.h#L71 - https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/solaris/native/java/io/io_util_md.c#L164 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 315745) Time Spent: 0.5h (was: 20m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 0.5h > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=315727=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315727 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 20/Sep/19 15:04 Start Date: 20/Sep/19 15:04 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533591180 @wy96f @clebertsuconic This should solve the memory leak issue with the minimum amount of changes. https://docs.oracle.com/javase/7/docs/api/java/io/RandomAccessFile.html#getChannel() doc shows that RandomAccessFile and FileChannel are required to always be in sync so NFS or other SAN storages cannot be unsynced due to using both to manipulate the underline file system This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 315727) Time Spent: 20m (was: 10m) > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 20m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-1811) NIOSequentialFile should use RandomAccessFile with heap ByteBuffers
[ https://issues.apache.org/jira/browse/ARTEMIS-1811?focusedWorklogId=315725=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315725 ] ASF GitHub Bot logged work on ARTEMIS-1811: --- Author: ASF GitHub Bot Created on: 20/Sep/19 15:03 Start Date: 20/Sep/19 15:03 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844 It use RandomAccessFile to allow using heap buffers without additional copies and/or leaks of direct buffers, as performed by FileChannel JDK implementation (see https://bugs.openjdk.java.net/browse/JDK-8147468) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 315725) Remaining Estimate: 0h Time Spent: 10m > NIOSequentialFile should use RandomAccessFile with heap ByteBuffers > --- > > 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 > Time Spent: 10m > Remaining Estimate: 0h > > JournalStorageManager::addBytesToLargeMessage and > LargeServerMessageImpl::DecodingContext::encode are 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 on > [https://bugs.openjdk.java.net/browse/JDK-8147468]) otherwise are freed right > after the write succeed. > If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are > always pooled regardless of the size, leading to OOM issues on high load of > variable sized writes due to the amount of direct memory allocated and not > released/late released. > 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 (v8.3.4#803005)
