[logback-user] OverlappingFileLockException when using common log among 2 tomcat contexts in same JVM.

[James Scollard]

We are currently deploying the following logback jar files to all tomcat 
instances:

logback-access-1.0.13.jar
logback-classic-1.0.13
logback-core-1.0.13

These libraries are currently deployed by Puppet to all Tomcat instances 
via the twc_tomcat module and are placed in the $CATALINA_HOME/lib 
directory to be accessible by all contexts. Additionally we are 
deploying puppet template (full variable and settings control) files for 
tomcat7.conf, server.xml, logback-access.xml, logback.xml, 
log4j.properties, and inbound/outbound-api-runtime.properties files to 
the $CATALINA_HOME/conf (alias) /etc/tomcat7 config directories.

If you keep a localhost version of the required configuration files in 
your WAR and then reference the external files (-Dconfig references) as 
preferred you will avoid any compiler errors while still allowing 
automated control of these properties.   We are also leveraging 
logrotate to ensure that files are maintained for a reasonable period 
but do not grow large enough to kill the node, and will be leveraging 
rsyslogd to eventually push copies of log messages to Logstash on a 
remote cluster.

Hopefully this helps.

On 9/19/13 10:57 AM, Christopher Holt wrote:
> David,
>
> If I move all of the logback, log4j, etc jars to tomcat/lib, then it 
> fails to find the logback.xml in my conf/Catalina/localhost directory.
>
> Jars involved:
>
> jcl-over-slf4j-1.7.5.jar
> jul-to-slf4j-1.7.5.jar
> log4j-over-slf4j-1.7.5.jar
> logback-access-1.0.13.jar
> logback-classic-1.0.13.jar
> logback-core-1.0.13.jar
> slf4j-api-1.7.5.jar
>
> I really want to keep the logback.xml config out of the war files. 
>  Different deployments will have different logging strategies.  I also 
> need separate logback.xml's per tomcat instance.  Where can I keep my 
> config so that it can be seen when the logback jars are not in the wars?
>
> Thanks,
> -Chris
>
>
>
> On Thu, Sep 19, 2013 at 3:53 AM, David Roussel 
> <nabble at diroussel.xsmail.com <mailto:nabble at diroussel.xsmail.com>> wrote:
>
>     Where is logback on the class path? If it is in the wars, try
>     taking it out and putting it in the tomcat class path.
>
>     David
>
>     On 18 Sep 2013, at 16:30, Christopher Holt <chris.holt at hcs.us.com
>     <mailto:chris.holt at hcs.us.com>> wrote:
>
>>     Hello,
>>
>>     I have logback configured so that code bundled in 2 different war
>>     files under tomcat will write to the same log file which rolls
>>     daily.  It's also marked as prudent.  I believe my configuration
>>     follows the guidelines from
>>     (http://logback.qos.ch/manual/appenders.html#prudentWithRolling).
>>
>>     <configuration>
>>       <appender name="A1"
>>     class="ch.qos.logback.core.rolling.RollingFileAppender">
>>         <prudent>true</prudent>
>>         <encoder>
>>                 <pattern>%d{dd-MM HH:mm:ss} [%t] %c %5p %m%n</pattern>
>>         </encoder>
>>         <rollingPolicy
>>     class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>>     <FileNamePattern>${catalina.base}/logs/myapp.%d{yyyy-MM-dd}.log</FileNamePattern>
>>     <MaxHistory>30</MaxHistory>
>>         </rollingPolicy>
>>       </appender>
>>
>>       <root level="INFO">
>>         <appender-ref ref="A1"/>
>>       </root>
>>     </configuration>
>>
>>     My problem is that I get lots
>>     of java.nio.channels.OverlappingFileLockException.
>>     ...
>>     java.nio.channels.FileChannel.lock(FileChannel.java:860)
>>     ch.qos.logback.core.FileAppender.safeWrite(FileAppender.java:187)
>>     ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:204)
>>     ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212)
>>     ...
>>
>>     After reading the docs for OverlappingFileLockException, my hunch
>>     is that the 2 different loggers, loaded by different class
>>     loaders within the same JVM are both trying to lock the file,
>>     unbeknownst to each other.  This violates the rules for
>>     FileChannel.lock, which seem to ignore the issue of locks among
>>     multiple class loaders within 1 JVM.
>>
>>     Has anyone run into this issue before?  Is there a simple
>>     workaround that I'm not thinking of?
>>
>>     Thanks,
>>     Chris
>>
>>     _______________________________________________
>>     Logback-user mailing list
>>     Logback-user at qos.ch <mailto:Logback-user at qos.ch>
>>     http://mailman.qos.ch/mailman/listinfo/logback-user
>
>     _______________________________________________
>     Logback-user mailing list
>     Logback-user at qos.ch <mailto:Logback-user at qos.ch>
>     http://mailman.qos.ch/mailman/listinfo/logback-user
>
>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user

-- 
James E. Scollard III

Senior Cloud Systems Architect
c: 615.730.4387
www.weather.com

View my profile on LinkedIn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20130919/50756030/attachment.html>