Apache::Session getting DESTROYed in wrong order
Hey, I'm having problems with Apache::Session, the symptom is that none of my data is getting written to the database. It's not the nested-data problem, since I'm not using any nested data structures. After some investigation, I've discovered that the Apache::Session::Store::MySQL::DESTROY routine is getting called before the Apache::Session::MySQL::DESTROY routine, so when the latter is called it doesn't have any way to write to the database. I think Perl is supposed to guarantee that the outer object's DESTROY is called before the inner object's, but I think maybe this guarantee doesn't extend to the "global destruction" phase. So I'm wondering why the session is getting cleaned up in global destruction rather than refcount destruction. I've declared %session as a locally-scoped variable, so it should evaporate before global destruction, unless it's got circular data structures or something. Anyone know what might be going on? This is Apache::Session version 1.53. Note: this problem isn't related to mod_perl, but IIRC this list is the proper place for discussing Apache::Session. -Ken
test, pls ignore
un/re subscribed to a different addy, THIS IS JUST A TEST!
[ANNOUNCE] Cache::Mmap 0.04
file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.04.tar.gz size: 14113 bytes md5: 649bdb9816f4177c0eb81c077fd7614c Much to my dismay and embarrassment, the serious bug fix in version 0.03 introduced a serious bug of it's own. You'll be pleased to hear that I've added a test suite (currently only one file) to the distribution, so this sort of thing should happen less in the future. Again, I strongly advise all users to upgrade to this version. I've also removed all the older versions from CPAN, just in case. This version also does the file locking in XS, thus removing the assumptions about struct flock's layout. It also does its own mmap()ing in XS, removing the dependency on Malcom Beattie's Mmap.pm. This means that people don't need to figure out Malcom's slightly strange distribution name, and it compiles on 5.6 without any problems (I've tested it on 5.004_05 too). >From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. -- Peter Haworth [EMAIL PROTECTED] "I don't know what kinds of evil I've done in the past. I don't even want to know. I just want that evil to carry on having its good effects" -- Damian Conway on his use of pack/unpack/vec
ANNOUNCE: AxKit 1.5
AxKit 1.5 is now available for download from both AxKit.org, and soon CPAN mirrors worldwide. This is a major upgrade, so please use caution when upgrading live servers, as major internal parts of AxKit have changed with this release. Most significantly, a large amount of code has been migrated to C, and some parts of the code have been migrated to use libxml2, which you should install prior to installing AxKit for optimum performance. It is now possible if you have libxml2 installed to run AxKit entirely without XML::Parser, which will help for people who can't recompile Apache (to remove the included expat). There have been many performance improvements in this release, too many to mention. Perhaps the most significant though is that AxKit is now a first class Apache handler (although it still requires mod_perl), so you can do: "SetHandler axkit", rather than have to use PerlHandler. This is a performance win, and will help if we ever need to move away from mod_perl to being a pure Apache module. For a full list of changes, please consult the axkit-users mailing list archives. Details of which are at http://axkit.org/mailinglist.xml Changes since AxKit 1.4_86 (beta): AxPoint added the ability to do bullet point transitions Fixed LibXSLT relative files with document() Fixed some core caching and delivery bugs Fixed MANIFEST missing files -- <:->Get a smart net
Re: Anyone know of specific problems with the malloc in Sun's libc?
On Sun, Dec 30, 2001 at 02:12:47PM -0600, Steven Lembark wrote: > > W/ current apache and mod_perl, perl-5.6.1, Solaris-2.8. > Been having problems with DBI dropping connections. One > suggestion was to override the default of "no" and use > the malloc that comes with perl-5.6.1. > Anyone know of problems or any obvious symptoms? I have not seen any problems with the Solaris malloc, in fact it seems that the VM behavior of our systems improved when we switched over. Consider setting the DBI_TRACE environment variable if you're having problems such as this. It will show you where your connections are going up and down. Does your DBD driver support pings? If not you should check out the Apache::DBI docs for info on how to roll your own.. If you feel like recompiling perl on solaris you might want to review the following options used to build perl with gcc 2.95.3. Seems to work well for us... CFLAGS='-pipe -mcpu=ultrasparc -mtune=ultrasparc -m32 -Wa,-xarch=v8plusa -O3 -ffast-math -fexpensive-optimizations' Configure -O -Dcc=gcc \ -Doptimize="@CFLAGS@" \ -Dlocincpth="@prefix@/include" \ -Dloclibpth="@prefix@/lib" \ [EMAIL PROTECTED] \ [EMAIL PROTECTED] \ -Ud_bincompat5005 \ -Ubincompat5005 \ -Uusemymalloc \ -Uinstallusrbinperl \ -Dlibperl=libperl.so \ -Duseshrplib=true \ -Dstatic_ext="Data/Dumper Fcntl IO POSIX Socket Sys/Hostname" \ -Ui_db \ -Ui_ndbm \ -Ui_ndbm \ -des -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: Fast template system
> Yeah, TT is good, all right, especially with the ability to change the
> start and end tags to something more compliant, like .
Uh ... why aren't you syntax-validating the actual HTML output by your
application?
Also, there are multiple syntax-checkerts that allow you to specify
validation rules.
>
> I'd gladly switch, if someone knows how to get it working on FreeBSD
> -STABLE without breaking everything else :-)
Quit using FreeBSD ports. Compile from source. Your problem is almost
certainly due to FreeBSD's weird installation of Perl, specifically its
library paths.
The best solution I've found is to create a new user 'perl' and install
Perl and all libraries etc under that user's home directory.
My system:
nick@world ~>uname -a
FreeBSD world.tonkinresolutions.com 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE
#1: Sat Aug 11 18:17:44 PDT 2001
[...]
nick@world ~>perl -v
This is perl, version 5.005_03 built for i386-freebsd
[...]
nick@world ~>perl -MTemplate -e 'print $Template::VERSION,"\n"'
2.06
- nick
Nick Tonkin {|8^)>
Re: AccelNoPass in mod_accel
On Mon, 31 Dec 2001, Philip Mak wrote: > Is there a way to specify an AccelNoPass directive (from mod_accel) that > only affects a certain directory? > > For example, consider the following scenario: > > AccelPass /~user1/ http://127.0.0.1:8001/ > AccelNoPass ~*\.gif$ ~*\.jpg$ > > AccelPass /~user2/ http://127.0.0.1:8002/ > AccelNoPass ~*\.gif$ > > Someone might want to specify separate AccelNoPass settings for those two > directories. It doesn't seem to work when I put it in though; > I get "AccelNoPass not allowed here" error. > > (I don't actually need this functionality at this point and I think it's > an obscure case, but I felt it was worth pointing out.) No. Both AccelPass and AccelNoPass run in translation phase and sets or does not set 'accel-handler'. So if AccelNoPass could run in or then it means that mod_accel needs to skip 'accel-handler' and found another one instead - mod_accel needs to run subrequest. I think it complicates processing and is not needed in many cases. Besides in your example case you can use such regexps: AccelNoPass ~*\.gif$ ~*^/~user1/.*\.jpg$ Igor Sysoev
AccelNoPass in mod_accel
Is there a way to specify an AccelNoPass directive (from mod_accel) that only affects a certain directory? For example, consider the following scenario: AccelPass /~user1/ http://127.0.0.1:8001/ AccelNoPass ~*\.gif$ ~*\.jpg$ AccelPass /~user2/ http://127.0.0.1:8002/ AccelNoPass ~*\.gif$ Someone might want to specify separate AccelNoPass settings for those two directories. It doesn't seem to work when I put it in though; I get "AccelNoPass not allowed here" error. (I don't actually need this functionality at this point and I think it's an obscure case, but I felt it was worth pointing out.)
Re: Fast template system
Ryan Thompson wrote: > Mark Maunder wrote to Ryan Thompson: > > > Ryan Thompson wrote: > > > > > There must be a faster way. I have thought about pre-compiling each > > > HTML file into a Perl module, but there would have to be an automated > > > (and secure) way to suck these in if the original file changes. > > > > > > Either that, or maybe someone has written a better parser. My code > > > looks something like this, to give you an idea of what I need: > > > > Sure there are tons of good template systems out there. I think > > someone made a comment about writing a template system being a > > right of passage as a perl developer. But it's also more fun to do > > it yourself. > > :-) > > > I guess you've tried compiling your regex with the o modifier? > > Yep, problem is there are several of them. I've done some work > recently to simplify things, which might have a positive effect. > > > Also, have you tried caching your HTML in global package variables > > instead of shared memory? I think it may be a bit faster than > > shared memory segments like Apache::Cache uses. (The first request > > for each child will be slower, but after they've each served once, > > they'll all be fast). Does your engine stat (access) the html file > > on disk for each request? You mentioned you're caching, but > > perhaps you're checking for changes to the file. Try to stat as > > My caching algorithm uses 2 levels: > > When an HTML file is requested, the instance of my template class > checks in its memory cache. If it finds it there, great... everything > is done within that server process. > > If it's not in the memory cache, it checks in a central MySQL cache > database on the local machine. These requests are on the order of a > few ms, thanks to an optimized query and Apache::DBI. NOT a big deal. > > If it's not in either cache, it takes it's lumps and goes to disk. > If you're using a disk based table, in most cases, mysql would access the disk itself anyway. So whether you're getting the cached data from mysql or a file, it's still coming from disk. (yes mysql caches - especially if you're using InnoDB tables, but you're not gauranteed to save a disk access). Not sure how much html/content you have, but any chance you can stick it all in shared memory, or even better, give each child their own copy in a package global variable (like a hashref)? If it's under a meg (maybe even 2) you might be able to get away with that. > > In each cache, I use a TTL. (time() + $TTL), which is configurable, > and usually set to something like 5 minutes in production, or 60 > seconds during development/bug fixes. (And, for this kind of data, 5 > minutes is pretty granular, as templates don't change very often.. but > setting it any higher would, on average, have only a negligible > improvement in performance at the risk of annoying developers :-). > > And, with debugging in my template module turned on, it has been > observed that cache misses are VERY infrequent (< 0.1% of all > requests). > > In fact, if I use this cache system and disable all parsing (i.e., > just use it to include straight HTML into mod_perl apps), I can serve > 150-200 requests/second on the same system. > > With my parsing regexps enabled, it drops to 50-60 requests/second. > > So, to me, it is clear where performance needs to be improved. :-) How about instead of having a cache expiry/TTL, you parse the HTML on the first request only and then always serve from the cache. To refresh the cache, you set a flag in shared memory. Then whenever a child is about to serve from cache, it just checks the flag in shared memory to see if it needs to refresh it's cache. That way you can 'push' out new code by just setting the flag and unsetting it once all running children have read from the cache. You'll also have every request served from the cache except the first. You'll also get the benifit of having each child serve live code for every request by keeping the flag set. That way your developers can code in realtime without a 60 second latency for new HTML to take effect when you want them to.
Anyone know of specific problems with the malloc in Sun's libc?
W/ current apache and mod_perl, perl-5.6.1, Solaris-2.8. Been having problems with DBI dropping connections. One suggestion was to override the default of "no" and use the malloc that comes with perl-5.6.1. Anyone know of problems or any obvious symptoms? thanx. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
