Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Avoiding file-locking when developing with embedded Jetty

On Thu, Jan 22, 2015 at 5:29 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> But the corresponding page in the new
> documentation doesn't seem to cover this as well. The scenario of the
> exploded webapp is missing at
> To be honest, I think that the old documentation with the simple
> non-commented code examples is more encouraging than the new with lots of
> embedded comments.

That's a bit disappointing considering the effort we've gone to to
improve the doco :(  Maybe might be a good idea to make a contribution
to the doco to put in the info that you really want to see:

Good point. I will look into that.

> Again, I'm mainly concerned about teachability. I have several times had
> people express "wow, this was really easy to get started with" and then a
> few hours laters start swearing about the locked files, only to throw Jetty
> away in disgust.
> To be honest, I think that you got the useFileMappedBuffer wrong. Perhaps
> the default should have been false? Perhaps the default should have been
> false if the resource was in the classpath?

Mmmn, well as we discussed, it is false in the code, and overridden to
be true by the webdefault.xml (which is of course replaceable). The
thing is, having it set to "true" is the right thing to do in both of
the following circumstances: 1. when running in production, 2. when
running on *nix. Now, most production servers are *nix machines, so
the setting makes a lot of sense. The only combination that is
problematic is Windows in development.

Getting something that works for everybody sounds hard.

What about disabling file mapped buffers for Windows?

Most people (hopefully) don't use Windows in production and even if they did, they are likely to use packaged WAR file rather than exploded resources on disk. Alternatively, I think I can make due if file mapped buffers are never used for classpath resources.

In the past, we've had this set around the other way, and we got
yelled at by all the *nix users because performance was worse. Now its
back to true, we get yelled at by the Windows users :).  We figure
that either one community or the other is going to have to change the
setting to suit, which is why we give you a number of different ways
to change it.

Perhaps this can be resolved simply by more (obvious) warnings in the

I will look into that after I return from my vacation next week. :-)


Back to the top