We Keep Coding

log4j2 Exception logging performance

We are using log4j2 for logging. After doing initial benchmark I have concluded that for same QPS, logging exception is 80 times slower than logging normal message.
Here is a sample error log message.
2022-08-25 11:09:14,699 - [pool-2-thread-1][{id=eb9bcf4f-1dcc-4cd7-8588-fd7916d623b8, path=/hellowworld}] - [Test2] ERROR - error wile doing something important java.lang.RuntimeException: exception
at Test2.recursiveCount(Test2.java:140) ~[logging.jar:?]
at Test2.recursiveCount(Test2.java:142) ~[logging.jar:?]
at Test2.recursiveCount(Test2.java:142) ~[logging.jar:?]
at Test2.access$000(Test2.java:17) ~[logging.jar:?]
at Test2$LoggerRunnable.run(Test2.java:75) ~[logging.jar:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_202]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
Here is a sample log message
2022-08-25 18:12:02,125 - [pool-2-thread-1][{id=90e8ebda-e02a-4c48-bc37-560190bda40a, path=/hellowworld}] - [Test2] INFO - adding log with number=ok uuid=1661431322125
It could be attributed to
Note: Logging exceptions and stack traces will create temporary objects with any layout. (However, Layouts will only create these temporary objects when an exception actually occurs.) We haven't figured out a way to log exceptions and stack traces without creating temporary objects. That is unfortunate, but you probably still want to log them when they happen.
source log4j2 documentation
Are there any config change that can be done to reduce the overhead of exception logging? Like
For similar stacktrace errors only log few sample stacktrace and not all the stack traces
limiting the deapth of stacktrace?
anything else?

What is the difference between LOGGER.error(exception.getMessage()) and LOGGER.error(exception.getMessage(), exception)

Like in this picture
I know that both of them works fine but I just wanted to know how are they different from each other? PS: I am a beginner.

A LogEvent can contain both a message and an exception. If you use the first form:
LOGGER.error(exception.getMessage());
only the error message will be recorded and you'll have a similar output in your logs (depends upon the layout):
[ERROR] - Exception message.
If you use the second form:
LOGGER.error(exception.getMessage(), exception);
you'll have both a message and an exception. This typically outputs the stack trace in the logs:
[ERROR] - Exception message.
java.lang.RuntimeException: Exception message.
at pl.copernik.log4j.Log4j2Test.run(Log4j2Test.java:19) [classes/:?]
at pl.copernik.log4j.Log4j2Test.main(Log4j2Test.java:15) [classes/:?]
Since you can always configure Log4j 2.x to suppress stack traces from the output (see alwaysWriteExceptions in the PatternLayout documentation), the second form is always better, as it provides more information.
Remark: Since the stack trace always prints the error's message, I'd suggest a third form:
LOGGER.error("An unexpected condition occurred while performing foo: {}",
exception.getMessage(), exception);
This way you can explain the context, when the exception occurred:
[ERROR] - An unexpected condition occurred while performing foo: Exception message.
java.lang.RuntimeException: Exception message.
at pl.copernik.log4j.Log4j2Test.run(Log4j2Test.java:19) [classes/:?]
at pl.copernik.log4j.Log4j2Test.main(Log4j2Test.java:15) [classes/:?]

java.lang.StackOverflowError when java.lang.ClassLoader.loadClass(ClassLoader.java:569)

I have these filling up in the catalina log file causing disk space issues when javaagent is attached. I have no idea from where there are getting triggered. What could be the reason ?
java.lang.StackOverflowError
at java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
at java.base/java.lang.ClassLoader.getClassLoadingLock(ClassLoader.java:668)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:569)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:576)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:576)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:576)
...........

Why does Camel noErrorHandler log warning message with stack trace?

We are using Camel 2.15.4 to connect our Swing clients to our OSGi server.
In the server, under certain circumstances, we throw a sub-class of RuntimeException which we want to propagate back to the client.
In the building of our routes we are using:
errorHandler(noErrorHandler());
But every time we throw one of these server errors, we get a WARN log message with a full stack trace. The testers are finding these log messages rather unnerving as they look like problems.
Is there any way to switch off the logging of these warnings?
Here's an example:
16:37:12,565 | WARN | che.camel.camel-core | Execution of JMS message listener failed. Caused by: [org.apache.camel.RuntimeCamelException]
org.apache.camel.RuntimeCamelException: xxxxxx.yyyyyyy.exceptions.CustomException: blah
at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1619)
at org.apache.camel.component.bean.BeanInvocation.invoke(BeanInvocation.java:87)
at org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:134)
at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
at org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:68)
at org.apache.camel.component.bean.BeanProducer.process(BeanProducer.java:38)
at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:129)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:91)
at uniworks.camel.interceptor.CamelInterceptor$1.process(CamelInterceptor.java:79)
at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:91)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)
at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87)
at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:103)[58:org.apache.camel.camel-jms:2.15.4]
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:569)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:507)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:474)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1103)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1095)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:992)[176:org.apache.servicemix.bundles.spring-jms:3.2.14.RELEASE_1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]
In the previous version of our server, which used Camel 2.11.0 and Spring DSL, we defined our route contexts with:
<camel:errorHandler id="noErrorHandler" type="NoErrorHandler"/>
<camel:camelContext id="blah_camel" errorHandlerRef="noErrorHandler">
.....
and we did not get these warning log messages.

That is actually not Camel's no error handler doing this logging but the JMS component. The JMS component has some fallback logging of exceptions to indicate the JMS message was not processeed successfully. You can see the two options: errorHandlerLoggingLevel and errorHandlerLogStackTrace on the JMS component/endpoint which you can turn off/configure: http://camel.apache.org/jms

Netty 4 leak exception at HttpObjectAggregator

I'm getting an exception on my netty server while it's under heavy load. (Testing with LOIC etc...) I want to know that I do something wrong or it's a bug in the HttpObjectAggregator.
WARNING: LEAK: ByteBuf was GC'd before being released correctly. The following stack trace shows where the leaked object was created, rather than where you failed to release it.
io.netty.util.ResourceLeakException: io.netty.buffer.CompositeByteBuf#1c0eeb6
at io.netty.util.ResourceLeakDetector$DefaultResourceLeak.<init>(ResourceLeakDetector.java:174)
at io.netty.util.ResourceLeakDetector.open(ResourceLeakDetector.java:116)
at io.netty.buffer.CompositeByteBuf.<init>(CompositeByteBuf.java:60)
at io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:138)
at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:50)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:334)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:320)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:334)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:320)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Thread.java:722)

Most likely you forgot to release the message after handling it. Did you call release() on it ?