Re: Modifying buffer size on runtime

"Piotr P. Karwasz" <[email protected]> Tue, 28 Jan 2025 19:41:21 +0100
Newsgroups gmane.comp.jakarta.log4j.user
Message-ID <[email protected]>
Hi Joan,

On 28.01.2025 19:12, [email protected] wrote:
> 1. I programmatically change it to 16K while the app is running:
> 	INFO: 2025-01-28T17:56:17.015816443Z main TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=16384
> 	
> 	I check the log4j2.xml file:
> 	 <RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="16384" immediateFlush="false">
> 	
> 	
> 2. Then I change it to 2K:
> 	INFO: 2025-01-28T17:57:47.216638176Z Log4j2-TF-1-ConfigurationFileWatcher-6 TRACE Configured node RollingRandomAccessFile Key[type: int; name: bufferSize; qualifierType: PluginBuilderAttribute]=2048
> 	
> 	Check:
> 	<RollingRandomAccessFile name="ACCESS_LOG" fileName="${sys:log.dir}vproxy_access" filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" bufferedIo="true" bufferSize="2048" immediateFlush="false">
> 			
> ...
>
> So, is it possible that changing the buffer size for this 'RollingRandomAccessFile' is not working on runtime?

Sorry, in my previous answer I didn't realize that your appender has the 
same `fileName` attribute before and after the change.

To implement reconfigurations without log event loss (which is one of 
the main differences between Log4j Core and Logback), Log4j Core splits 
most appenders into a skinny appender and a manager. The manager takes 
care of the underlying resource, e.g. keeps a file open, rotates it, 
keeps a TCP/UDP file open, etc. Managers are accessed through a global 
static registry by name (a representation of the resource accessed, such 
as path for a file) and are reference counted. This is a killer feature:

* If Log4j Core is installed in the common Tomcat classloader, multiple 
application (with different logger contexts) can safely log to the same 
file. There will be only one manager.

* When you reconfigure Log4j Core, the "old" rolling file appender 
passes the manager to the "new" rolling file appender, so the log file 
is never closed.

Unfortunately for your use-case, this also means that some configuration 
attributes (those that are used by the manager) can not be changed by 
reconfiguration. For that to happen, the appender should be removed and 
then created again or you can change the path to the log file.

We tried to document it under each appender (see for example the note in 
the Appenders section[1]) and in the architecture page[2]. Feel free to 
suggest documentation changes to make this behavior clearer: there is an 
"Edit this Page" on each documentation page, so you can easily make a PR.

Piotr

[1] 
https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#appenders

[2] 
https://logging.apache.org/log4j/2.x/manual/architecture.html#AbstractManager