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)
...........
Related
I have a strange "infinite loop" in log4j2.
I found it in the tomcat catalina.out and have to idea where it comes from because there is no other packages involved the whole error stack trace.
Is this a know bug or did I configure something wrong.
The version of log4j2 I'm using is 2.17.1
2022-01-25 01:17:03,517 WARN org.apache.commons.logging.LogAdapter$Log4jLog caught java.lang.StackOverflowError logging SimpleMessage: Application exception overridden by rollback exception java.lang.StackOverflowError
at org.apache.logging.log4j.util.StringBuilders.appendSpecificTypes(StringBuilders.java:79)
at org.apache.logging.log4j.message.ParameterFormatter.appendSpecialTypes(ParameterFormatter.java:484)
at org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:473)
at org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:448)
at org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:191)
at org.apache.logging.log4j.message.ParameterizedMessage.formatTo(ParameterizedMessage.java:227)
at org.apache.logging.log4j.message.ParameterizedMessage.getFormattedMessage(ParameterizedMessage.java:203)
at org.apache.logging.log4j.message.ParameterizedNoReferenceMessageFactory.newMessage(ParameterizedNoReferenceMessageFactory.java:105)
at org.apache.logging.log4j.message.AbstractMessageFactory.newMessage(AbstractMessageFactory.java:99)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2057)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1931)
at org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:2805)
at org.apache.logging.log4j.spi.AbstractLogger.handleLogMessageException(AbstractLogger.java:2225)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2208)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2058)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1931)
at org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:2805)
at org.apache.logging.log4j.spi.AbstractLogger.handleLogMessageException(AbstractLogger.java:2225)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2208)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2058)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1931)
at org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:2805)
at org.apache.logging.log4j.spi.AbstractLogger.handleLogMessageException(AbstractLogger.java:2225)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2208)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2058)
I'm debugging a piece of code in Eclipse. When I try to get the info of an object I'm getting a lot of null values in the info window (Ctrl+Shift+i), but it shows the right values at the bottom of the same window. Pic of the issue below:
Request by: user7294900
Request by: howlger
Can you tell me why this is happen? Is this the right behaviour?
I am currently migrating to richfaces 4.5, JSF2.2 and also add primefaces-6.0 (for other feature that is not supported by richfaces)
I am using Tomcat 8 for the server.
At the xhtml file, I just put simple code below just to test this :
<rich:fileUpload id="upload"
fileUploadListener="#{cc.attrs.beanPage.uploadListener}"
maxFilesQuantity="1"
acceptedTypes=".ppt, .pptx, .doc, .docx, .txt, .xls, .xlsx, .zip, .pdf" />
and at the uploadListener I only put some thing just to debug
public void uploadListener(FileUploadEvent event) {
this.item = event.getUploadedFile();
String projectFileName = this.item.getName();
}
When I debug I see it reach the listener and end without error. But I am getting this error below after the listener finished:
java.lang.StackOverflowError
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:679)
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:643)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:86)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91).. keep repeating
Jul 15, 2016 4:09:36 PM org.primefaces.application.exceptionhandler.PrimeExceptionHandler logException
SEVERE: null
java.lang.StackOverflowError
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:679)
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:643)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:86)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91)... keep repeating
Jul 15, 2016 4:09:38 PM org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/PORTAL].[Faces Servlet] invoke
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/PORTAL] threw exception [Servlet execution threw an exception] with root cause
java.lang.StackOverflowError
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:679)
at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:643)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:86)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91)
at org.richfaces.context.AjaxOutputTracker.getAjaxOutputs(AjaxOutputTracker.java:91)..... and so on keep repeating
Previously its working in old version.. Any idea on what I am doing wrong? I suspect there is a configuration that I missed that cause this.
After some testing here and there, I actually manage to fix this. The fix is just put limitRender="true" and it fix this problem.
This might be a very simple problem, but I actually don't understand why is this necessary, since I don't put any render in this fileupload. I might miss something in the form.
Edit: After some check, I find there is ajaxRendered=true in the page, but I don't know why it giving recursive overflow issue, since its not render each other. I might be missing something.
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?
I have a java webapp using an ibatis row handler to load a very large dataset (1 million rows in an innodb table). The process is run as a nightly cron job by quartz scheduler. However, after it processes for 6 minutes, it dies with the following stack trace:
WARN [DefaultQuartzScheduler_Worker-8] MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(168) | Could not invoke method 'doBatch' on target object [org.myCron#4adb34]
org.springframework.jdbc.UncategorizedSQLException: SqlMapClient operation: encountered SQLException [
--- The error occurred in org/myCron/mySqlMap.xml.
--- The error occurred while applying a result map.
--- Check the mySqlMap.outputMapping.
--- The error happened while setting a property on the result object.
--- Cause: com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception:
** BEGIN NESTED EXCEPTION **
java.io.EOFException
STACKTRACE:
java.io.EOFException
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1903)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2402)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2860)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:771)
at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1289)
at com.mysql.jdbc.RowDataDynamic.nextRecord(RowDataDynamic.java:362)
at com.mysql.jdbc.RowDataDynamic.next(RowDataDynamic.java:352)
at com.mysql.jdbc.ResultSet.next(ResultSet.java:6106)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:168)
at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at com.ibatis.common.jdbc.logging.ResultSetLogProxy.invoke(ResultSetLogProxy.java:47)
at $Proxy10.next(Unknown Source)
at com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor.java:380)
at com.ibatis.sqlmap.engine.execution.SqlExecutor.handleMultipleResults(SqlExecutor.java:301)
at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:190)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQuery(GeneralStatement.java:205)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithRowHandler(GeneralStatement.java:133)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryWithRowHandler(SqlMapExecutorDelegate.java:649)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryWithRowHandler(SqlMapSessionImpl.java:156)
at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryWithRowHandler(SqlMapClientImpl.java:133)
at org.springframework.orm.ibatis.SqlMapClientTemplate$5.doInSqlMapClient(SqlMapClientTemplate.java:267)
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:165)
at org.springframework.orm.ibatis.SqlMapClientTemplate.queryWithRowHandler(SqlMapClientTemplate.java:265)
at org.myCron.doBatch(MyCron.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:248)
at org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$MethodInvokingJob.executeInternal(MethodInvokingJobDetailFactoryBean.java:165)
at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:66)
at org.quartz.core.JobRunShell.run(JobRunShell.java:191)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
** END NESTED EXCEPTION **
The stack trace is very vague. The only hints that I see are 'the error happened while setting a property on the result object'. There are only two properties on the result object: a String and an Integer. Both of them permit null values, but my select statements indicate that neither of them have any null values. They both have a proper gettter/setter (which makes sense since the process runs for a while successfully before dying). Every time that the cron runs, it dies at a random point (so it isn't stuck on a particular row).
Note - The method 'doBatch' does exist since that is the method that starts the cron process. If it couldn't find doBatch, it couldn't successfully process the first thousand rows.
I've also tried runnning the job outside of quartz and it also fails there as well. We tried increasing our MySQL net_read_timeout, net_write_timeout, and delayed_insert_timeout but none of these settings helped with the problem. I also tried setting my log4j setting to DEBUG and I did not get any helpful info.
Any other ideas about what I could try?
Sounds like MySQL closed the connection for some reason. Check the MySQL log see if anything shows up. Turn on various logging options for MySQL if necessary.
Also, start printing debug data (including timestamp) from your app - just print everything, then see what the last action was - perhaps you have some rarely triggered conditions in your code that has a bug.
I.e. every single time you talk to MySQL log it before AND after.