Re: [jetty-users] useFileMappedBuffer doesn't appear to disable memory m

[Karen Murphy <k.l.murphy@xxxxxxxxx>]

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