It would also help to see the stack trace being logged. Gary
On Tue, Dec 2, 2014 at 1:07 PM, Gary Gregory <[email protected]> wrote: > FYI: the stack trace does not match with our current git master level > sources which is not surprising since we are evolving and fixing things. > > If you had a little program that could reproduce the issue that would be > great. > > You can also use a 2.2-SNAPSHOT from the Apache snapshot repo (or build > from sources too). > > Gary > > On Tue, Dec 2, 2014 at 12:57 PM, Gary Gregory <[email protected]> > wrote: > >> Can you try version 2.1? >> >> Gary >> >> On Tue, Dec 2, 2014 at 12:46 PM, Mariano Gonzalez < >> [email protected]> wrote: >> >>> Hello, >>> >>> I'm progamatically creating an appender with the following code: >>> >>> private static final String PATTERN_LAYOUT = "%-5p %d [%t] %c: %m%n"; >>> >>> private RollingFileAppender createRollingFileAppender(String logFilePath, >>> String filePattern, String appenderName, Configuration configuration) >>> { >>> TriggeringPolicy triggeringPolicy = >>> TimeBasedTriggeringPolicy.createPolicy("1", "true"); >>> RolloverStrategy rolloverStrategy = >>> DefaultRolloverStrategy.createStrategy("30", "1", null, >>> String.valueOf(Deflater.NO_COMPRESSION), configuration); >>> >>> return RollingFileAppender.createAppender(logFilePath, >>> logFilePath + filePattern, >>> "true", >>> appenderName, >>> "true", >>> null, null, >>> triggeringPolicy, >>> rolloverStrategy, >>> createLayout(configuration), >>> null, null, null, null, >>> configuration); >>> } >>> >>> private Layout<? extends Serializable> createLayout(Configuration >>> configuration) >>> { >>> return PatternLayout.createLayout(PATTERN_LAYOUT, configuration, >>> null, >>> null, true, false, null, null); >>> } >>> >>> Sometimes, not always, when an exception is thrown I end up seeing the >>> following error: >>> >>> 2014-12-02 14:36:52,092 ERROR An exception occurred processing Appender >>> defaultFileAppender java.lang.ArrayIndexOutOfBoundsException: 53 >>> >>> at >>> >>> org.apache.logging.log4j.core.impl.ThrowableProxy.formatElements(ThrowableProxy.java:227) >>> >>> at >>> >>> org.apache.logging.log4j.core.impl.ThrowableProxy.getExtendedStackTraceAsString(ThrowableProxy.java:401) >>> >>> at >>> >>> org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverter.format(ExtendedThrowablePatternConverter.java:72) >>> >>> at >>> >>> org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:36) >>> >>> at >>> >>> org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:189) >>> >>> at >>> >>> org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:53) >>> >>> at >>> >>> org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:52) >>> >>> at >>> >>> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:104) >>> >>> at >>> >>> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:86) >>> >>> at >>> >>> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:97) >>> >>> at >>> >>> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:428) >>> >>> at >>> >>> org.apache.logging.log4j.core.async.AsyncLoggerConfig.asyncCallAppenders(AsyncLoggerConfig.java:118) >>> >>> at >>> >>> org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigHelper.java:222) >>> >>> at >>> >>> org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigHelper.java:207) >>> >>> at >>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128) >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> >>> at java.lang.Thread.run(Thread.java:745) >>> >>> >>> I noticed that it doesn't happen for every exception, but when it does >>> happen, it happens consistently. I also noticed that it's the causedTrace >>> array the one that usually falls short. Is this a known issue? Any way I >>> can get a fix? Maybe with a different layout? I'm using log4j 2.0.2 >>> >>> >>> Thanks you! >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
