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?

NPE in Spring Integration LoggingHandler

I'm facing some weird NPE with no details thrown by org.springframework.integration.handler.LoggingHandler. The previous log entry is 2 minutes before which is also strange.
Does anyone have any idea what can be the reason behind it?
2017-07-25 18:33:38.561 DEBUG o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of singleton bean 'markEodPositionsAsProcessedChannel'
2017-07-25 18:35:36.985 ERROR o.s.integration.handler.LoggingHandler : org.springframework.messaging.MessageHandlingException: nested exception is java.lang.NullPointerException
at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:96)
at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:89)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:109)
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:127)
at org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:116)
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:148)
at org.springframework.integration.dispatcher.UnicastingDispatcher.access$000(UnicastingDispatcher.java:53)
at org.springframework.integration.dispatcher.UnicastingDispatcher$3.run(UnicastingDispatcher.java:129)
at org.springframework.integration.util.ErrorHandlingTaskExecutor$1.run(ErrorHandlingTaskExecutor.java:55)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException

The code you talk about looks like:
public T processMessage(Message<?> message) {
try {
return this.delegate.process(message);
}
catch (Exception e) {
throw new MessageHandlingException(message, e);
}
}
The clearly means that delegate.process() throws NPE somehow.
According to the StackTrace you have some Service Activator to call your POJO service method. And that looks like exactly your method already throws that NPE.
I also believe that there is something else in the StackTrace after Caused by: java.lang.NullPointerException.
You see that as an ERROR in your logs, because you have some polling flow starting from some source - Inbound Channel Adapter. And any exception thrown downstream are caught by the error handler in the Poller Ednpoint and sent to the errorChannel with the LoggingHandler as a default subscriber.
See Reference Manual for more info.

OPC client issue

I am getting the following error in the OPC client code.
I start my client- close it - start it again to see the following error.
It is clear that something from previous run is causing it. But I am unable to figure out what it is.
When I diff the jstack of my first run and close. I do not see any running thread from opc.
Has anyone seen this issue? Or
Is there some other way I can debug the issue?
2016-05-19 16:35:53,564 WARN [netty-event-loop-0] io.netty.channel.ChannelInitializer - Failed to initialize a channel. Closing: [id: 0xe25cac5b] java.lang.ExceptionInInitializerError
at com.digitalpetri.opcua.stack.client.UaTcpStackClient$1.initChannel(UaTcpStackClient.java:340)
at com.digitalpetri.opcua.stack.client.UaTcpStackClient$1.initChannel(UaTcpStackClient.java:337)
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:69)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:133)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:119)
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:449)
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:377)
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:423)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: 'awaiting-handshake' is already in use
at io.netty.util.UniqueName.<init>(UniqueName.java:53)
at io.netty.util.AttributeKey.<init>(AttributeKey.java:47)
at io.netty.util.AttributeKey.valueOf(AttributeKey.java:39)
at com.digitalpetri.opcua.stack.client.handlers.UaTcpClientAcknowledgeHandler.<clinit>(UaTcpClientAcknowledgeHandler.java:44)
... 13 more

Looks like you might have some kind of ClassLoader issue - a static final field of UaTcpAcknowledgeHandler is being defined twice somehow.
What exactly happens when you "close" your client?

java.net.SocketException: Broken pipe with SMTP

I got strange behavior when my application tries to send an email.
20:59:08,926 ERROR [release.com.mycompany.mail.GenericMail] (EJB default - 5) [MY_EJB INBOUND] Sending message failed!: javax.mail.MessagingException: Can't send command to SMTP host;
nested exception is:
java.net.SocketException: Broken pipe
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:2106) [mail-1.4.4-redhat-2.jar:1.4.4-redhat-2]
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:2093) [mail-1.4.4-redhat-2.jar:1.4.4-redhat-2]
at com.sun.mail.smtp.SMTPTransport.close(SMTPTransport.java:1184) [mail-1.4.4-redhat-2.jar:1.4.4-redhat-2]
at javax.mail.Transport.send0(Transport.java:197) [mail-1.4.4-redhat-2.jar:1.4.4-redhat-2]
at javax.mail.Transport.send(Transport.java:124) [mail-1.4.4-redhat-2.jar:1.4.4-redhat-2]
at com.mycompany.MailUtils.sendMail(MailUtils.java:258) [classes:]
Before this exception some timeout exception has been thrown:
20:57:50,291 ERROR [org.jboss.as.ejb3] (EJB default - 9) [ ] JBAS014122: Error during
retrying timeout for timer: [id=6be904b5-c1ef-4f0e-a277-d4c9f93e21b3 timedObjectId=SOME_EJB
auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl#99fdab1 initialExpiration=/* date */ 00:00:00 UTC 2015 intervalDuration(in milli sec)=0 nextExpiration=/* other date */ 21:00:00 UTC 2015
timerState=RETRY_TIMEOUT: javax.ejb.EJBTransactionRolledbackException: JBAS014373:
EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation#66668127 - could not obtain lock within 5000MILLISECONDS
To be honest i don't know whats happened. I got these kind of exception for 5 hours.
I want to know whats happened and be able to avoid exceptions in future.
UPDATE 1
SOME_EJB is an ejb with works with timerService. Runs every 3 minutes, when the conditions are met sends an email.
My only idea is that there was some network/database issue and it caused that single execution of task took more than 3 minutes.
MailUtils is a #Stateless ejb

Is the mail sent or not?
It looks like JavaMail is closing the connection to the mail server when the exception occurs. If a previous error caused the server to drop the connection immediately, JavaMail may be getting this exception while trying to send the SMTP BYE command before closing the connection.
Turn on JavaMail Session debugging to see what error the server might have reported before this exception occurs.

JTA transaction unexpectedly rolled back, nested exception is javax.transaction.RollbackException

I am getting UnexpectedRollbackException. Here is the complete stack trace:
org.springframework.transaction.UnexpectedRollbackException: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is javax.transaction.RollbackException
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:732)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635)
at com.cmates.userIcon.service.IconUpdaterServiceImpl$$EnhancerByCGLIB$$78838aa7.persist(<generated>)
at com.cmates.userIcon.service.ScheduledIconUpdaterServiceImpl.doScheduledTask(ScheduledIconUpdaterServiceImpl.java:125)
at com.cmates.profile.services.IconSyncSingletonImpl.process(IconSyncSingletonImpl.java:121)
at com.cmates.profile.services.IconSyncJob.executeInternal(IconSyncJob.java:25)
at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:86)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525)
Caused by: javax.transaction.RollbackException
at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:245)
at org.objectweb.jotm.Current.commit(Current.java:488)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
... 13 more
[18 Apr 2011 00:54:00,590] ERROR ErrorLogger - Job (DEFAULT.iconSyncJob threw an exception.
This Exception suddenly started showing in my logs. I didn't made any changes in my code.
I guess this might be due to a timeout?

I'm seeing a mention of a quartz job in the stacktrace. Looks like something has setup a periodic job and the AOP transaction management has picked up on it.

It looks like your transaction lasts than transaction timeout limit. You should increase transaction timeout limit..
But I am not sure about that, you should post more stack trace to understand the reason of rollback.