AxKit 1.62
XML-LibXML-1.58_1
XML-LibXSLT-1.57
libxml2-2.6.14
libxslt-1.1.11
(I've also tried with 2.6.8 / 1.0.33 - no luck. Doesn't seem related...)
The first symptom of an error was one I'd seen before: Can't locate object method "cache_params" via package ... It would never occur on the first hit to a page, but randomly after a few hits - and then it would never stop. Turning off caching (AxNoCache On) seemed to do the trick, and I thought I could live with it as a development box...
... until I got Mason running, which we're using for several other sites. Mason was unable to write it's own internal caching files, and further digging there was giving me some incredibly strange errors involving file descriptors. As a test, I stripped down http.conf to no AxKit references except for "PerlModule AxKit" - and it still broke Mason. Removing that line made Mason work. AxKit to blame?
So I dug back into AxKit -- and it's the same basic error I was seeing in Mason: a filehandle is opened without error, and print is called on it. The print also does not fail, but it DOES NOT PRINT anything to the file! Then when close is called on the filehandle it finally fails with a "Bad file descriptor" error. Cache.pm does not check for failure on the close, but here is the code I changed (line 120 I think):
print $fh $_[0] or throw Apache::AxKit::Exception::IO( -text => "Couldn't write cachefile: $!");
close $fh or throw Apache::AxKit::Exception::IO( -text => "Couldn't close cachefile: $!");
And the output logfile:
[Wed Oct 27 16:41:30 2004] [warn] [client 63.171.110.130] [AxKit] about to execute: Apache::AxKit::Language::XSP::handler
[Wed Oct 27 16:41:31 2004] [warn] [client 63.171.110.130] [AxKit] Cache: key = 523bd0e2913bf4ab6aada7cc6a3a00f2
[Wed Oct 27 16:41:31 2004] [warn] [client 63.171.110.130] [AxKit] XSP: parsing fh
[Wed Oct 27 16:41:31 2004] [warn] [client 63.171.110.130] [AxKit] XSP: Parser returned doc
[Wed Oct 27 16:41:31 2004] [warn] [client 63.171.110.130] [AxKit] [Cache] writing cache file /tmp/caldev_axkit_cache//52/3b/d0e2913bf4ab6aada7cc6a3a00f2
[Wed Oct 27 16:55:57 2004] [error] [client 63.171.110.130] [AxKit] [Error] Parse of '/home/axkit/schools/index.wac' failed: Couldn't close cachefile: Bad file descriptor
This does not happen every time! Sometimes (rarely) a page's XSP will be successfully written! But when a page does fail the cache file exists (empty), so Axkit tries to load it and compile it, leading to the inevitable 'Can't locate object method "cache_params"' message. In AxKit I can avoid this by disabling caching, but it's breaking other modules and I don't want to keep hacking file handling - it seems broken.
More details: there are plenty of file descriptors left, kern.maxfiles is 3544, and if I look at fstat on the newly created filehandle (before and after the print) it shows that it's indeed open for the correct process and is writable!! Anyone know what can cause print to succeed but not actually write? Why would the close fail??
Anyone ever seen anything like this? I've been banging my head on it for two solid days and nights, trying various configurations, everything I can think of. I wasted a lot of time debugging Mason - but it seems something in the AxKit startup code is breaking file descriptors? Is that even possible? Are there any other library versions I need to be checking?
Thanks in advance for any input on this. I'm totally stumped. Nate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
