Re: Chainsaw Zeroconf FileAppender Error

[Scott Deboy]

I used jmdns 3.4.2 with the latest log4j2 and a sample app that used
the following appender configuration to log to a local file.  Chainsaw
was able to discover the advertisement and live tail the log file.

It looks like the latest JmDNS has changed their API, so log4j2 works
with jmdns 3.4.1, not their latest, right now.

Example appender config:



  





%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - 
%m%n


  
  

  

  


In Chainsaw's 'connect to' menu, I had a 'File1 option'.  I clicked on
it, and a new tab opened with the contents of the file - it's
live-tailing the log file.

On the appender config, advertiseURI could be an ssh endpoint, using
Apache Commons VFS 'sftp' support, instead of a 'file://' URI.  For
example, if you can ssh from your env running Chainsaw to the app
performing the logging, you could use an advertiseURI of something
like:

sftp://username:password@hostname/Users/admin/log4j2-output.log



On 4/18/17, Mohit Garg  wrote:
> -- Forwarded message --
> From: Mohit Garg 
> Date: Tue, Apr 18, 2017 at 10:24 PM
> Subject: Chainsaw Zeroconf FileAppender Error
> To: log4j-user@logging.apache.org
>
>
> Hi,
>
> I am using Apache Chainsaw on an Ubuntu 14.04 machine. In my Java
> application I have the advertised my FileAppender URI as follows:
>
>  advertiseURI="file:///path/to/output.log" advertise="true">
> 
> 
>
> In Zeroconf tab of Chainsaw I can see the Appender File1. However, when i
> try to connect to it I continuously get the following error.
>
> Failed to connect to remote host 
> Reconnecting in 3000 ms
>
> ---and so on
>
>
> --
> Thanks and Regards,
> Mohit Garg
>
> Masters|Computer Engineering
> Virginia Polytechnic Institute
> and State University
>
> <+1-540-449-3550>   
>    
>
>
>
>
> --
> Thanks and Regards,
> Mohit Garg
>
> Masters|Computer Engineering
> Virginia Polytechnic Institute
> and State University
>
> <+1-540-449-3550>   
>    
>

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

Fwd: Chainsaw Zeroconf FileAppender Error

[Mohit Garg]

-- Forwarded message --
From: Mohit Garg 
Date: Tue, Apr 18, 2017 at 10:24 PM
Subject: Chainsaw Zeroconf FileAppender Error
To: log4j-user@logging.apache.org


Hi,

I am using Apache Chainsaw on an Ubuntu 14.04 machine. In my Java
application I have the advertised my FileAppender URI as follows:





In Zeroconf tab of Chainsaw I can see the Appender File1. However, when i
try to connect to it I continuously get the following error.

Failed to connect to remote host 
Reconnecting in 3000 ms

---and so on


-- 
Thanks and Regards,
Mohit Garg

Masters|Computer Engineering
Virginia Polytechnic Institute
and State University

<+1-540-449-3550>   
   




-- 
Thanks and Regards,
Mohit Garg

Masters|Computer Engineering
Virginia Polytechnic Institute
and State University

<+1-540-449-3550>   
   

Re: Using Log4J2 2.8 (via the 1.2 API Bridge) for Tomcat8 Internal Logging - RollingFileAppender does not (cannot?) create new Log File

[Ankit Agarwal]

 

On Monday, April 10, 2017 5:20 PM, Remko Popma  
wrote:
 

 >If you enable internal Log4j2 logging with  at 
 >the top of your configuration, then you should see internal Log4j2 logging on 
 >the console. 
>It should show details of what happens during a rollover. Can you post that 
>output?
My original hypothesis was wrong. The problem does not arise during a rollover.

Here is what I have found so far. I see this behavior on my development machine.
I did not use the Tomcat 8 installation for the entire weekend, i.e., 2 days or 
so. Did not use means that I did not visit my web application via a browser, 
did not deploy a new WAR, did not restart Tomcat, etc. I just left it running 
as is.
Sometime during the weekend, Tomcat zipped up my log files - catalina.out, 
localhost.log, manager.log, and even my web applications own log file which is 
written to a sub-directory of "/var/log/tomcat8".
>From the zip file timestamps it looks like this was approximately 24 hours 
>after I last used Tomcat.
Once the zip files were created, replacement log files were not created.
Now, when I visit the web application via a browser, no logs are written (as 
there is no log file). No error is added to "catalina.out" either. It is 0 
bytes since the last catalina.out file was zipped up.
If I try to redeploy my WAR, it fails and there is no error in the Tomcat Admin 
Manager UI - this is because the localhost.log file has been zipped and a new 
one has not been created. If I restart the Tomcat, this problem will go away.

Interestingly, the catalina.log file does not have this problem, and I believe 
it is because I have the TRACE level logging enabled as you had suggested. So 
Tomcat is writing logs to catalina.log every second (even when it is idle).
Given all this, the only logs I have are from the catalina.log file and they 
are of this type:
18 Apr 2017 16:35:23,472 "2017-04-18T16:35:23,472" "CMS" "Tomcat" "" "" "" "" 
"" "" "52.25.59.238" "59" "http-nio-443-ClientPoller-1" "" "" "" "[]" 
"org.apache.tomcat.util.net.NioEndpoint$Poller.timeout(NioEndpoint.java:1318)" 
"TRACE" "timeout completed: keys processed=0; now=1492558523472; 
nextExpiration=1492558523471; keyCount=0; hasEvents=false; eval=false"
18 Apr 2017 16:35:23,904 "2017-04-18T16:35:23,904" "CMS" "Tomcat" "" "" "" "" 
"" "" "52.25.59.238" "54" 
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" "" "" "" "[]" 
"org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1249)" 
"DEBUG" "Checking context[] redeploy resource /var/lib/tomcat8/webapps/ROOT.war"

It seems that Tomcat (or Log4J/Log4J2) automatically zips up log files after 
inactivity of 24 hours or so and fails to create replacement log files.

Any thoughts on this? Has you seen this kind of behavior before?

Thanks,Ankit


Sent from my iPhone

> On Apr 11, 2017, at 4:07, Ankit Agarwal  
> wrote:
> 
> Hi,
> 
> I’m using Log4J2 (2.8) via the 1.2 API Bridge for Tomcat 8 internal logging.
> 
> I followed the instructions here: 
> https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j 
> 
> - With the exception that I also copied the Bridge JAR into the Tomcat8 lib 
> directory
> 
> I have configured Log4J2 with this XML file
> 
> 
> 
>    
>          ${sys:catalina.base}/logs
>          CMS
>          Tomcat
>          ${env:PUBLIC_IP_ADDRESS}
>          
>          %d{DATE} "%d{ISO8601}" "${systemName}" 
>"${componentName}" "%X{clientIpAddress}" "%X{clientTcpPort}" "%X{username}" 
>"%X{sessionId}" "%X{sessionAuthenticationId}" "%X{sessionAuthenticationToken}" 
>"${serverIpAddress}" "%T" "%t" "%X{apiName}" "%X{apiSystemActionType}" 
>"%X{apiSystemItemType}" "%x" "%l" "%p" "%m"%n%n
>    
>    
>          
>              
>          
>          filePattern="${logDirectory}/catalina-%i.log.gz">
>              
>              
>                    
>              
>              
>          
>          fileName="${logDirectory}/localhost.log" 
>filePattern="${logDirectory}/localhost-%i.log.gz">
>              
>              
>                    
>              
>              
>          
>          filePattern="${logDirectory}/manager-%i.log.gz">
>              
>              
>                    
>              
>              
>          
>          fileName="${logDirectory}/host-manager.log" 
>filePattern="${logDirectory}/host-manager-%i.log.gz">
>              
>              
>                    
>              
>              
>          
>    
>    
>          
>              
>          
>          name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost]" 
>level="info" additivity="false">
>              
>          
>          name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]"
> level="info" additivity="false">
>              
>          
>          

Re: anomalies running log4j v 2.2 on Tomcat

[Remko Popma]

I can partially answer that. The LoggerContext name has changed a few times. I 
actually thought it's the other way around and the older versions of Log4j2 use 
a web app name-based LoggerContext name. It turned out that some web containers 
generate web context names that are multiple lines and contain line breaks. 
This created problems in Log4j2 JMX where the LoggerContext name is used in the 
ObjectName of all MBeans. Because of these JMX issues I changed the 
LoggerContext name to a unique short string (the hashcode of the LoggerContext 
object). 

Are you sure it's the older version of Log4j2 that has numeric LoggerContext 
names? Anyway, other than JMX the LoggerContext name isn't used anywhere so it 
should not cause any issues. 

Perhaps someone else can answer your question about the MarkerLookup 
ClassCastException. 

Glad to hear Log4j2 is working well for you. 
Remko 

Sent from my iPhone

> On Apr 19, 2017, at 0:33, COHEN, STEVEN M  wrote:
> 
> I would be grateful for any input the members of this list can provide about 
> the following situation.
> 
> We are running Tomcat 8.0.39, deploying on it a number of web applications 
> using log4j2, the jars for which are packaged into the war files. These 
> webapps are built in various environments.  One build environment (our "old" 
> environment) cannot build with any JDK > 1.6.  Therefore it uses Log4j2 v.2.2 
> and embeds these jars into the war files it produces.  Tomcat itself is 
> running JDK 1.8.
> 
> In catalina.out, we see the following error messages on startup whenever a 
> webapp built in the "old" environment is loaded.
> There are two anomalies:
> 1) the logger context names are numeric.  On those built with JDK1.8 and 
> log4j 2.5+ they are derived from the name of the Webapp.
> 2) the ClassCastException errors.
> 
> In spite of the errors, the affected applications do seem to produce the logs 
> that they have been configured to produce.
> 
> Are these errors a product of using such an old version of log4j2?  Would we 
> expect them to disappear with a more modern version?  Do they indicate a 
> serious problem?
> 
> Yes, I know we should be using a more modern JDK and Log4j, but inertia is a 
> powerful force.  :-(
> 
> Thanks in advance for any information anyone is able to provide.
> 
> 2017-04-17 20:24:34,035 DEBUG Starting LoggerContext[name=1728191654] from 
> configuration at file:///usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml
> 2017-04-17 20:24:34,036 DEBUG Starting LoggerContext[name=1728191654, 
> org.apache.logging.log4j.core.LoggerContext@207a11b8] with configuration 
> XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml]...
> 2017-04-17 20:24:34,038 DEBUG Shutdown hook enabled. Registering a new one.
> 2017-04-17 20:24:34,040 DEBUG Starting configuration 
> XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml]
> 2017-04-17 20:24:34,041 DEBUG PluginManager 'Core' found 98 plugins
> 2017-04-17 20:24:34,041 DEBUG PluginManager 'Level' found 0 plugins
> 2017-04-17 20:24:34,047 DEBUG PluginManager 'Lookup' found 14 plugins
> 2017-04-17 20:24:34,048 ERROR Unable to create Lookup for marker 
> java.lang.ClassCastException: class 
> org.apache.logging.log4j.core.lookup.MarkerLookup
>at java.lang.Class.asSubclass(Class.java:3404)
>at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:64)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:346)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
>at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359)
>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:169)
>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:204)
>at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:109)
>at 
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:157)
>at 
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:107)
>at 
> org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57)
>at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5303)
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
>at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:753)
>at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:729)
>at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
>at 
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:940)
>at 
> 

Re: Max index limit in DefaultRolloverStrategy

[Ralph Goers]

FYI - the documentation for the web site is in the project at 
src/site/xdoc/manual.  You can create a patch for that the same way you would 
patch any of the java source.

Ralph

> On Apr 18, 2017, at 10:20 AM, Chandra  
> wrote:
> 
> Hi Gary,
> 
> I’d love to, but this ticket is primarily to change the documentation and 
> it’d have a minor amendments in the document on the website. I’m not exactly 
> sure how to send a patch to this :-/
> 
> 1)
> https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy
> 
> Particularly, the section "DefaultRolloverStrategy Parameters” :
> 
> From:
> max - Integer -  The maximum value of the counter. Once this values is 
> reached older archives will be deleted on subsequent rollovers.
> 
> To :
> max - Integer - The maximum value of the counter. Once this values is reached 
> older archives will be deleted on subsequent rollovers (The default value is 
> 7).
> 
> 2) Also, I’d also _recommend_ to update the Javadoc (this I can send a patch 
> :) ) but, I think it’s not required.
> 
> thanks,
> Chandra
> 
> On 18 Apr 2017, 8:53 PM +0530, Gary Gregory , wrote:
>> Patches welcome ;-)
>> 
>> Gary
>> 
>> 
>> On Apr 18, 2017 1:18 AM, "Chandra" > wrote:
>> 
>> Hi guys, any update on this ticket?
>> https://issues.apache.org/jira/browse/LOG4J2-1877
>> 
>> 
>> thanks,
>> Chandra
>> 
>> On 12 Apr 2017, 12:14 AM +0530, Chandra 
>> ,
>> wrote:
>>> Yes, that’d be great. 7 seems to too low for frequently filled logs.
>>> And also guys, please document it. I am raising a JIRA ticket in this
>> regards ( thanks Remko for the reminder).
>>> Also yes, I have set a default purge policy, this is 90 days in our use
>> case.
>>> 
>>> Best,
>>> Chandra
>>> 
>>> On 12 Apr 2017, 12:07 AM +0530, Ralph Goers ,
>> wrote:
 I believe starting with 2.8.1 we no longer scan the directory so it is
>> much faster. We could probably raise the default limit.
 
 Ralph
 
> On Apr 11, 2017, at 11:12 AM, Remko Popma > wrote:
> 
> Sorry to hear that!
> 
> You are right that the docs currently don't mention the default value
>> for
> the max attribute.
> We should fix the docs. Can I ask you to raise a Jira for this?
> 
> As for why not a large default value, there is a performance impact:
>> all
> files within the range need to be renamed (bump version by one), and
>> the
> current logic scans the directory to look for files that match the
>> pattern.
> 
> You may be interested in the custom Delete action which is more
>> efficient (
> https://logging.apache.org/log4j/2.x/manual/appenders.
>> html#CustomDeleteOnRollover
> ).
> 
> 
> On Mon, Apr 10, 2017 at 2:50 PM, Chandra <
> chandra.tungathur...@rwth-aachen.de> wrote:
> 
>> Hi guys,
>> 
>> Something I noticed in my production, the maximum limit of index
>> (i.e.,
>> the max #files to be rolled before an overwrite occurs) is 7 by
>> default.
>> This is not mentioned anywhere in any of the documentation. I was
>> only
>> able to confirm this by actually looking into the source code [1].
>> Unfortunately, by the time we noticed there was huge data loss.
>> 
>> I wanted to confirm:
>> * Why is the default max index set to 7? I was naive to think that
>> the
>> default max index would be set to a large value (may be no max
>> index at
>> all, perhaps)
>> * Why wasn’t this mentioned anywhere in the documentation (if it
>> is, can
>> you point me to it. may be I wasn’t paying attention). If it
>> happened to
>> me, perhaps it might for others.
>> 
>> 
>> 
>> Best,
>> Chandra
>> 
>> 
>> 
>> [1] https://github.com/apache/logging-log4j2/blob/master/
>> log4j-core/src/main/java/org/apache/logging/log4j/core/
>> appender/rolling/
>> DefaultRolloverStrategy.java#L126
>> 
 
 
 
 -
 To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-user-h...@logging.apache.org
 



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

Re: Max index limit in DefaultRolloverStrategy

[Chandra]

Hi Gary,

I’d love to, but this ticket is primarily to change the documentation and it’d 
have a minor amendments in the document on the website. I’m not exactly sure 
how to send a patch to this :-/

1)
https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy

Particularly, the section "DefaultRolloverStrategy Parameters” :

From:
max - Integer -  The maximum value of the counter. Once this values is reached 
older archives will be deleted on subsequent rollovers.

To :
max - Integer - The maximum value of the counter. Once this values is reached 
older archives will be deleted on subsequent rollovers (The default value is 7).

2) Also, I’d also _recommend_ to update the Javadoc (this I can send a patch :) 
) but, I think it’s not required.

thanks,
Chandra

On 18 Apr 2017, 8:53 PM +0530, Gary Gregory , wrote:
> Patches welcome ;-)
>
> Gary
>
>
> On Apr 18, 2017 1:18 AM, "Chandra"  wrote:
>
> Hi guys, any update on this ticket?
> https://issues.apache.org/jira/browse/LOG4J2-1877
>
>
> thanks,
> Chandra
>
> On 12 Apr 2017, 12:14 AM +0530, Chandra ,
> wrote:
> > Yes, that’d be great. 7 seems to too low for frequently filled logs.
> > And also guys, please document it. I am raising a JIRA ticket in this
> regards ( thanks Remko for the reminder).
> > Also yes, I have set a default purge policy, this is 90 days in our use
> case.
> >
> > Best,
> > Chandra
> >
> > On 12 Apr 2017, 12:07 AM +0530, Ralph Goers ,
> wrote:
> > > I believe starting with 2.8.1 we no longer scan the directory so it is
> much faster. We could probably raise the default limit.
> > >
> > > Ralph
> > >
> > > > On Apr 11, 2017, at 11:12 AM, Remko Popma  wrote:
> > > >
> > > > Sorry to hear that!
> > > >
> > > > You are right that the docs currently don't mention the default value
> for
> > > > the max attribute.
> > > > We should fix the docs. Can I ask you to raise a Jira for this?
> > > >
> > > > As for why not a large default value, there is a performance impact:
> all
> > > > files within the range need to be renamed (bump version by one), and
> the
> > > > current logic scans the directory to look for files that match the
> pattern.
> > > >
> > > > You may be interested in the custom Delete action which is more
> efficient (
> > > > https://logging.apache.org/log4j/2.x/manual/appenders.
> html#CustomDeleteOnRollover
> > > > ).
> > > >
> > > >
> > > > On Mon, Apr 10, 2017 at 2:50 PM, Chandra <
> > > > chandra.tungathur...@rwth-aachen.de> wrote:
> > > >
> > > > > Hi guys,
> > > > >
> > > > > Something I noticed in my production, the maximum limit of index
> (i.e.,
> > > > > the max #files to be rolled before an overwrite occurs) is 7 by
> default.
> > > > > This is not mentioned anywhere in any of the documentation. I was
> only
> > > > > able to confirm this by actually looking into the source code [1].
> > > > > Unfortunately, by the time we noticed there was huge data loss.
> > > > >
> > > > > I wanted to confirm:
> > > > > * Why is the default max index set to 7? I was naive to think that
> the
> > > > > default max index would be set to a large value (may be no max
> index at
> > > > > all, perhaps)
> > > > > * Why wasn’t this mentioned anywhere in the documentation (if it
> is, can
> > > > > you point me to it. may be I wasn’t paying attention). If it
> happened to
> > > > > me, perhaps it might for others.
> > > > >
> > > > >
> > > > >
> > > > > Best,
> > > > > Chandra
> > > > >
> > > > >
> > > > >
> > > > > [1] https://github.com/apache/logging-log4j2/blob/master/
> > > > > log4j-core/src/main/java/org/apache/logging/log4j/core/
> appender/rolling/
> > > > > DefaultRolloverStrategy.java#L126
> > > > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > >

anomalies running log4j v 2.2 on Tomcat

[COHEN, STEVEN M]

I would be grateful for any input the members of this list can provide about 
the following situation.

We are running Tomcat 8.0.39, deploying on it a number of web applications 
using log4j2, the jars for which are packaged into the war files. These webapps 
are built in various environments.  One build environment (our "old" 
environment) cannot build with any JDK > 1.6.  Therefore it uses Log4j2 v.2.2 
and embeds these jars into the war files it produces.  Tomcat itself is running 
JDK 1.8.

In catalina.out, we see the following error messages on startup whenever a 
webapp built in the "old" environment is loaded.
There are two anomalies:
1) the logger context names are numeric.  On those built with JDK1.8 and log4j 
2.5+ they are derived from the name of the Webapp.
2) the ClassCastException errors.

In spite of the errors, the affected applications do seem to produce the logs 
that they have been configured to produce.

Are these errors a product of using such an old version of log4j2?  Would we 
expect them to disappear with a more modern version?  Do they indicate a 
serious problem?

Yes, I know we should be using a more modern JDK and Log4j, but inertia is a 
powerful force.  :-(

Thanks in advance for any information anyone is able to provide.

2017-04-17 20:24:34,035 DEBUG Starting LoggerContext[name=1728191654] from 
configuration at file:///usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml
2017-04-17 20:24:34,036 DEBUG Starting LoggerContext[name=1728191654, 
org.apache.logging.log4j.core.LoggerContext@207a11b8] with configuration 
XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml]...
2017-04-17 20:24:34,038 DEBUG Shutdown hook enabled. Registering a new one.
2017-04-17 20:24:34,040 DEBUG Starting configuration 
XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml]
2017-04-17 20:24:34,041 DEBUG PluginManager 'Core' found 98 plugins
2017-04-17 20:24:34,041 DEBUG PluginManager 'Level' found 0 plugins
2017-04-17 20:24:34,047 DEBUG PluginManager 'Lookup' found 14 plugins
2017-04-17 20:24:34,048 ERROR Unable to create Lookup for marker 
java.lang.ClassCastException: class 
org.apache.logging.log4j.core.lookup.MarkerLookup
at java.lang.Class.asSubclass(Class.java:3404)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:64)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:346)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359)
at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:169)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:204)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:109)
at 
org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:157)
at 
org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:107)
at 
org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5303)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:753)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:729)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:940)
at 
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1816)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

2017-04-17 20:24:34,051 ERROR Unable to create Lookup for main 
java.lang.ClassCastException: class 
org.apache.logging.log4j.core.lookup.MainMapLookup
at java.lang.Class.asSubclass(Class.java:3404)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:64)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:346)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359)
at 

Re: Max index limit in DefaultRolloverStrategy

[Gary Gregory]

Patches welcome ;-)

Gary


On Apr 18, 2017 1:18 AM, "Chandra" 
wrote:

Hi guys, any update on this ticket?
https://issues.apache.org/jira/browse/LOG4J2-1877


thanks,
Chandra

On 12 Apr 2017, 12:14 AM +0530, Chandra ,
wrote:
> Yes, that’d be great.  7 seems to too low for frequently filled logs.
> And also guys, please document it. I am raising a JIRA ticket in this
regards ( thanks Remko for the reminder).
> Also yes, I have set a default purge policy, this is 90 days in our use
case.
>
> Best,
> Chandra
>
> On 12 Apr 2017, 12:07 AM +0530, Ralph Goers ,
wrote:
> > I believe starting with 2.8.1 we no longer scan the directory so it is
much faster. We could probably raise the default limit.
> >
> > Ralph
> >
> > > On Apr 11, 2017, at 11:12 AM, Remko Popma 
wrote:
> > >
> > > Sorry to hear that!
> > >
> > > You are right that the docs currently don't mention the default value
for
> > > the max attribute.
> > > We should fix the docs. Can I ask you to raise a Jira for this?
> > >
> > > As for why not a large default value, there is a performance impact:
all
> > > files within the range need to be renamed (bump version by one), and
the
> > > current logic scans the directory to look for files that match the
pattern.
> > >
> > > You may be interested in the custom Delete action which is more
efficient (
> > > https://logging.apache.org/log4j/2.x/manual/appenders.
html#CustomDeleteOnRollover
> > > ).
> > >
> > >
> > > On Mon, Apr 10, 2017 at 2:50 PM, Chandra <
> > > chandra.tungathur...@rwth-aachen.de> wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Something I noticed in my production, the maximum limit of index
(i.e.,
> > > > the max #files to be rolled before an overwrite occurs) is 7 by
default.
> > > > This is not mentioned anywhere in any of the documentation. I was
only
> > > > able to confirm this by actually looking into the source code [1].
> > > > Unfortunately, by the time we noticed there was huge data loss.
> > > >
> > > > I wanted to confirm:
> > > > * Why is the default max index set to 7? I was naive to think that
the
> > > > default max index would be set to a large value (may be no max
index at
> > > > all, perhaps)
> > > > * Why wasn’t this mentioned anywhere in the documentation (if it
is, can
> > > > you point me to it. may be I wasn’t paying attention). If it
happened to
> > > > me, perhaps it might for others.
> > > >
> > > >
> > > >
> > > > Best,
> > > > Chandra
> > > >
> > > >
> > > >
> > > > [1] https://github.com/apache/logging-log4j2/blob/master/
> > > > log4j-core/src/main/java/org/apache/logging/log4j/core/
appender/rolling/
> > > > DefaultRolloverStrategy.java#L126
> > > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >

Re: Buffering in Console Appender?

[Jaromir Hamala]

Hello Mikael,

this fix was already merged

into Surefire. It made a massive difference difference in our cases: as
confirmed by both data from Java Flight Recorder and real-world experience
(build stability).

I guess in our case the effect was amplified by the fact our Continuous
Integration runs on AWS where:
1. I/O is rather slow in general
2. EC2 instance have certain number of "burst I/O credits" <- when they are
exhausted then I/O becomes dog-slow.

Cheers,
Jaromir

On Tue, Apr 18, 2017 at 10:12 AM, Mikael Ståldal 
wrote:

> If you add this, don't forget to do some performance tests to verify that
> it actually improves performance.
>
> On Fri, Apr 14, 2017 at 1:33 PM, Jaromir Hamala 
> wrote:
>
> > Hello Matt,
> >
> > thanks for you reply. I realized this is something what should
> > probably be handled inside Surefire and not inside Log4J.
> >
> > I'll talk to Surefire folks.
> >
> > Cheers,
> > Jaromir
> >
> > On Thu, Apr 13, 2017 at 7:23 PM, Matt Sicker  wrote:
> >
> > > Sounds like an interesting use case. Patches are always welcome! Make
> > sure
> > > to file a JIRA ticket as well so we have something to refer to in the
> > > changelog.
> > >
> > > On 13 April 2017 at 09:29, Jaromir Hamala 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I wonder whether log4j could add (optional) buffering into the
> Console
> > > > Appender.
> > > > I believe it could be useful e.g. when the stdout is redirected to a
> > file
> > > > (think of Maven Surefire), etc.
> > > >
> > > > Would you accept a patch adding this?
> > > >
> > > > Cheers,
> > > > Jaromir
> > > >
> > > > --
> > > > “Perfection is achieved, not when there is nothing more to add, but
> > when
> > > > there is nothing left to take away.”
> > > > Antoine de Saint Exupéry
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> >
> >
> >
> > --
> > “Perfection is achieved, not when there is nothing more to add, but when
> > there is nothing left to take away.”
> > Antoine de Saint Exupéry
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



-- 
“Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.”
Antoine de Saint Exupéry

Re: Max index limit in DefaultRolloverStrategy

[Chandra]

Hi guys, any update on this ticket?
https://issues.apache.org/jira/browse/LOG4J2-1877


thanks,
Chandra

On 12 Apr 2017, 12:14 AM +0530, Chandra , 
wrote:
> Yes, that’d be great.  7 seems to too low for frequently filled logs.
> And also guys, please document it. I am raising a JIRA ticket in this regards 
> ( thanks Remko for the reminder).
> Also yes, I have set a default purge policy, this is 90 days in our use case.
>
> Best,
> Chandra
>
> On 12 Apr 2017, 12:07 AM +0530, Ralph Goers , 
> wrote:
> > I believe starting with 2.8.1 we no longer scan the directory so it is much 
> > faster. We could probably raise the default limit.
> >
> > Ralph
> >
> > > On Apr 11, 2017, at 11:12 AM, Remko Popma  wrote:
> > >
> > > Sorry to hear that!
> > >
> > > You are right that the docs currently don't mention the default value for
> > > the max attribute.
> > > We should fix the docs. Can I ask you to raise a Jira for this?
> > >
> > > As for why not a large default value, there is a performance impact: all
> > > files within the range need to be renamed (bump version by one), and the
> > > current logic scans the directory to look for files that match the 
> > > pattern.
> > >
> > > You may be interested in the custom Delete action which is more efficient 
> > > (
> > > https://logging.apache.org/log4j/2.x/manual/appenders.html#CustomDeleteOnRollover
> > > ).
> > >
> > >
> > > On Mon, Apr 10, 2017 at 2:50 PM, Chandra <
> > > chandra.tungathur...@rwth-aachen.de> wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Something I noticed in my production, the maximum limit of index (i.e.,
> > > > the max #files to be rolled before an overwrite occurs) is 7 by default.
> > > > This is not mentioned anywhere in any of the documentation. I was only
> > > > able to confirm this by actually looking into the source code [1].
> > > > Unfortunately, by the time we noticed there was huge data loss.
> > > >
> > > > I wanted to confirm:
> > > > * Why is the default max index set to 7? I was naive to think that the
> > > > default max index would be set to a large value (may be no max index at
> > > > all, perhaps)
> > > > * Why wasn’t this mentioned anywhere in the documentation (if it is, can
> > > > you point me to it. may be I wasn’t paying attention). If it happened to
> > > > me, perhaps it might for others.
> > > >
> > > >
> > > >
> > > > Best,
> > > > Chandra
> > > >
> > > >
> > > >
> > > > [1] https://github.com/apache/logging-log4j2/blob/master/
> > > > log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/
> > > > DefaultRolloverStrategy.java#L126
> > > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >

Re: Buffering in Console Appender?

[Mikael Ståldal]

If you add this, don't forget to do some performance tests to verify that
it actually improves performance.

On Fri, Apr 14, 2017 at 1:33 PM, Jaromir Hamala 
wrote:

> Hello Matt,
>
> thanks for you reply. I realized this is something what should
> probably be handled inside Surefire and not inside Log4J.
>
> I'll talk to Surefire folks.
>
> Cheers,
> Jaromir
>
> On Thu, Apr 13, 2017 at 7:23 PM, Matt Sicker  wrote:
>
> > Sounds like an interesting use case. Patches are always welcome! Make
> sure
> > to file a JIRA ticket as well so we have something to refer to in the
> > changelog.
> >
> > On 13 April 2017 at 09:29, Jaromir Hamala 
> > wrote:
> >
> > > Hello,
> > >
> > > I wonder whether log4j could add (optional) buffering into the Console
> > > Appender.
> > > I believe it could be useful e.g. when the stdout is redirected to a
> file
> > > (think of Maven Surefire), etc.
> > >
> > > Would you accept a patch adding this?
> > >
> > > Cheers,
> > > Jaromir
> > >
> > > --
> > > “Perfection is achieved, not when there is nothing more to add, but
> when
> > > there is nothing left to take away.”
> > > Antoine de Saint Exupéry
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>
>
> --
> “Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.”
> Antoine de Saint Exupéry
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.