You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by jo...@ventusproxy.com on 2025/01/28 18:12:23 UTC

Modifying buffer size on runtime

Hi Piotr,

One more thing I've seen. Finally, I'm modifying directly in the log4j2.xml file the buffer size of one of my loggers. I have enabled the debug, the log4j2 xml file has a monitor interval of 30 seconds.

I start my application with a buffer of 8K. Then:

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">
			
			
The point is that, while I'm logging, the ratio of lines that are logged is always the same, with 2048 it should be continually logging and with 16384 I should see pauses between two consecutive loggings. But not.

Then, if I restart the application, it works as expected.

So, is it possible that changing the buffer size for this 'RollingRandomAccessFile' is not working on runtime?

Thanks,

Joan.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Modifying buffer size on runtime

Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Joan,

On 28.01.2025 19:12, joan.balaguero@ventusproxy.com 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



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org