Re: mod_dav_fs locking / Re: apr_dbm and concurrency

Joe Orton <[email protected]>
Newsgroups gmane.comp.apache.apr.devel
Organization Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US)
Message-ID <ZWBmHJbBv7dUX7ke__17587.4923051865$1700817310$gmane$org@redhat.com>
On Thu, Nov 23, 2023 at 05:42:10PM +0000, Emmanuel Dreyfus wrote:
> On Thu, Nov 23, 2023 at 05:36:06PM +0000, Joe Orton wrote:
> > 3) in the mean time I worked up a PR for mod_dav_fs which adds a global 
> > mutex around the dbm lockdb use. This passes my stress tests for the 
> > first time.
> 
> How concurent is the stress test? 

I've been testing with 20 concurrent clients on an 8 core machine.

> In the past, I have been badly hurt by a few WebDAV clients proactively 
> exploring the filesystem using locksdiscovery. That compeltely killed the 
> service. I introduced the DavLockDiscovery directive to work it around.

This is a good point. Was the load in that case PRPOFIND/depth:infinity 
do you know or "just" depth:1? A global lock like in my PR would make 
the PROPFIND load even worse, since the lock is held for the duration of 
the response and there are no concurrent read-only locks.

It might be necessary to disable lock discovery by default then, I don't 
know if any clients rely on or expose that but it's only a "MAY" that 
lock discvovery is possible in RFC4918. I suspect the lock recovery 
mechanism for most users & clients is to delete the lockdb.

Regards, Joe
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.