theit commented on issue #695:
URL: https://github.com/apache/maven-mvnd/issues/695#issuecomment-1263718981
No, this gives me the same error.
I investigated a bit in the code trying to figure out at what part the
exception occurs, and finally found a way out (workaround?) by explicitely
triggering the garbage collector in `DaemonRegistry.java`:
```
--- a/common/src/main/java/org/mvndaemon/mvnd/common/DaemonRegistry.java
+++ b/common/src/main/java/org/mvndaemon/mvnd/common/DaemonRegistry.java
@@ -262,6 +262,7 @@ public class DaemonRegistry implements AutoCloseable {
LOGGER.info("Resizing registry to {} kb due to
buffer underflow", (size / 1024));
l.release();
BufferHelper.closeDirectByteBuffer(buffer,
LOGGER::debug);
+ System.gc();
channel.truncate(size);
try {
buffer =
channel.map(FileChannel.MapMode.READ_WRITE, 0, size);
```
Reason:
You first release the file lock and then call a helper method to close the
mapped byte buffer before truncating the file. The Javadoc for MappedByteBuffer
states:
"A mapped byte buffer and the file mapping that it represents remain valid
until the buffer itself is garbage-collected."
It seems that at least on my environment (Windows 10 x64 with the initially
mentioned Java version(s)) this doesn't work as desired b/c the byte buffer
still exists...
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
