[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jetty-users] useFileMappedBuffer doesn't appear to disable memory mapped log file created from webapp - Jetty 7.3 - Apache Commons Daemon
|
Hi Joakim,
This is very useful thanks.
I have a separate and slightly earlier version of shibboleth IdP (2.3.6)
on a Windows Server 2003, running under Apache Tomcat which doesn't have
the problem. This system and the new one I referred to in my original
email both have the same version of Java, 1.6.0_33.
I'm trying to understand the difference between these systems with
regard to this problem. Does Apache Tomcat handle the interactions
differently to Jetty ?
Both these Shib IdP's (which create these logs) use the same version of
logback (1.0.0).
Thanks for your advice,
Karen
From: Joakim Erdfelt <joakim@xxxxxxxxxxx>
Date: Tue, 9 Apr 2013 06:52:24 -0700
Delivered-to: jetty-users@xxxxxxxxxxx
The useFileMappedBuffer is only for files being served by the
DefaultServlet, not for logging.
Depending on your logging implementation that is creating that file, you
could be hitting a long standing Windows bug.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715154
Note: this has been closed as "wontfix" way back in the days of Java 1.4
and is still a known bug even today in Java 1.8.
In short, if java has accessed the file, chances are high that the file
is locked in windows.
There is no logic or reason to the file locking that windows forces on you.
As you use newer and newer versions of java, this chance of locking
actually increases as more and more processes within java are using NIO.
Properly closing a simple file can sometimes help, as it makes the file
available to read by another process, but it can still be locked from
being deleted, moved, or renamed.
The most common file locking bug with java is with jar and zip files in
the classpath, as the standard jar and zip implementations maintains
various caches that hold references to those jar and zip files.
--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
webtide.com
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Tue, Apr 9, 2013 at 6:32 AM, Karen Murphy <k.l.murphy@xxxxxxxxx> wrote:
>
> Hi,
>
> I'm trying to determine if Jetty 7.3 can be configured to 'deal with
> locked windows files' when the file (shibboleth idp-process.log) exists
> outside of the jetty directory and is written to from a context deployed
> webapp (IdP) under Jetty.
>
> I was able to disable file memory mapping for CSS/JSP files inside of
> %JETTY_HOME%' using instructions in this link:
>
http://docs.codehaus.org/**display/JETTY/Files+locked+on+**Windows<http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows>
>
> Unfortunately it didn't work for the shibboleth logfile, which results in
> daily log rotation failing.
>
> My Shibboleth IdP 2.3.8 is running under jetty 7.3, which is running as a
> service on Windows Server 2008 using Apache daemons - procrun.
>
> I read the following post:
>
http://jira.codehaus.org/**browse/JETTY-1513<http://jira.codehaus.org/browse/JETTY-1513>
>
> I installed "Handle" from technet.microsoft (targetted at searching for
> open file references) and the output of this command on idp-process:
>
> Handle v3.51
> Copyright (C) 1997-2013 Mark Russinovich
> Sysinternals - www.sysinternals.com
>
> java.exe pid: 3688 type: File 5F8:
> C:\opt\shibboleth-idp\logs\**idp-process.log
>
> I'm trying to understand if this is a locking issue with Jetty or with
> Apache Commons Procrun ?
>
> Any help or pointers with this would be greatly appreciated,
>
> Thanks and Kind Regards
>
> Karen
>
>
> --
> *Karen Murphy*
> Systems Analyst - Bibliographic Services
> The Library at Queen's
> Queen's University Belfast
> Belfast BT7 1LP
> Tel: 028 90976260
> Email: k.l.murphy@xxxxxxxxx