This content has been marked as final. Show 4 replies
960076 wrote:It's not garbage values, it's just the values what happened to be in the memory.
the file shows the rest of the size as some garbage value.
Is there any way to avoid this problem?Yes. Don't use memory mapping if the file size might change or you can't truncate it.
Also, unless this is a school project you really shouldn't be building a logging framework.
First of all I want to inform you that mine is not a school project, and that's the reason I'm looking for such a logging framework, which should be faster and reliable.
We have some critical logging and those should not affect the application throughput. Currently we have that inefficiency with Logback. That's why I'm here with memory mapping.
So you are saying that I can't avoid the unwanted bytes while using the existing memory mapping ?.
MappedByteBuffers aren't much use on a file that you need to extend: you need to close and reopen, and there is no official way of unmapping them. You'd be far better off looking at a BufferedWriter with a large buffer size.
For logging, it's tough to get speed and reliability. one option to decouple the log writing from the application throughput, however, is to move the log writing to a separate thread (aka "write behind"). change the main "log" calls to just push the log record onto a queue and use a separate thread to monitor the queue and actually write the changes to disk. logback may have such an option already built in. obviously, you lose a bit on reliability here as you may have records in memory which get lost in the event of a crash.