Your message dated Wed, 6 Dec 2006 11:12:37 +0100
with message-id <[email protected]>
has caused the Debian Bug report #400329,
regarding wwwoffle: lock-files in concurrent downloading broken either way
to be marked as having been forwarded to the upstream software
author(s) [email protected]
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Re: Bug#400329: wwwoffle: lock-files in concurrent downloading broken either way
Wed, 6 Dec 2006 11:12:37 +0100
please take a look at the following Debian bug report.
I've written a few comments at the end.
(Please preserve [email protected] in the CC: list when
responding, so that your responses can be tracked by the Debian BTS.)
On Sat 25 Nov 2006, Tim Connors wrote:
> Subject: Bug#400329: wwwoffle: lock-files in concurrent downloading broken
> either way
> From: Tim Connors <[email protected]>
> To: Debian Bug Tracking System <[email protected]>
> Package: wwwoffle
> Version: 2.9-2
> Severity: grave
> Justification: causes non-serious data loss
> wwwoffle has the setting:
> # lock-files = yes | no
> # Enable the use of lock files to stop more than one WWWOFFLE process
> # from downloading the same URL at the same time (default=no).
> Either way this is set, it is broken.
> If set to yes, it seems that a lockfile only manages to tell the
> second process to give up loading the page at all, giving back a HTTP
> 500 WWWOFFLE Server Error:
> > for i in `seq 1 10 ` ;do lynx -dump http://www.google.com.au & done
> WWWOFFLE - World Wide Web Offline Explorer - v2.9
> WWWOFFLE Server Error
> The WWWOFFLE server encountered a fatal error:
> Cannot open the spooled web page to read.
> The program cannot continue to service this request.
> This is an internal WWWOFFLE server error that should not occur. There
> is no other way of handling the error apart from providing this
> warning page. If this error continues and WWWOFFLE is configured
> correctly and there are no other computer problems then you should
> report the error to the WWWOFFLE author.
> WWWOFFLE - [Welcome Page|FAQ] - WWWOFFLE
> 1. http://scuzzie:8080/Welcome.html
> 2. http://scuzzie:8080/FAQ.html
> By loading many pages at once as above, some of them end up succeeding
> after the cache has been loaded, but prior to that, all but one of
> them are going to fail -- above I'd see 5 or so error pages, then 5 or
> so successful downloads -- YMW(ill)V as my computer is probably slow
> enough for this test to come out this way.
> If set to no, then the first process to hit the cache gets their
> download, but the second process only retrieves as much as had reached
> the first process at that time. So the second download ends up
> incomplete. No error is returned, so it may not even be apparent
> until a later date -- hence dataloss.
> Marked as grave because of dataloss, since any webpage using crappy
> session management, or submition of forms, etc, ends up being broken
> whenever the page is being concurrently loaded in two seperate
> pages/processes with either setting, and one copy will not be complete
> or will fail altogether. Most of the rest of the time, a reload ought
> to fix it, but this sometimes ends up loading from the browser's own
> cache, which has only been half downloaded (I can't seem to convince
> opera to drop its version of its cache, and reload from the proxy)
I've responded that it's not a grave loss of data, as that's what the
option is for; say "yes" if you want to prevent that.
That said, the error you get when a page is indeed locked, is a bit
unexpected: "This is an internal WWWOFFLE server error that should not
occur." It's after all a documented option...
IMHO the second process should wait for the completion of the first
download process before proceeding; giving an "500 WWWOFFLE Server
Error" is not the right thing to do here...
--- End Message ---