Hi,
what you really want is an intelligent caching behaviour:
1. Generate PDF if not exists in Filesystem (the advantage is that
multiple processes have a access to this PDF) or BerkleyDB for
example
2a. Sent Generatated PDF from Cache
2b. Regenerate PDF if underlying data has been modified and restore for
later
[3. A cronjob which cleans up your disk-cache from time to time]Code looks like the following(Apache2):
-------------------------8<------------------------- use Apache::RequestIO (); use Apache::RequestRec (); use Apache::Constants ();
sub handler {
my $r;
## ....
my $cache_key = md5( $user . $path );
my $file = "/tmp/pdf-cache/$cache_key.pdf";
my $rc; if( -e $file && stat($_[0])[9] > stat($path)[9] ) {
eval {
$r->sendfile($file);
} if( ! $@ ) {
return Apache::OK;
}
}## create your PDF like you've done before ## ....
open( CACHEFILE, ">$file" );
print CACHEFILE $content;
close( CACHEFILE )
}
-------------------------8<-------------------------Dermot Paikkos wrote:
Hi Tom,
I think I see what your saying. What if you ignored the first and worked on the 2nd? Same problem I guess if you hit the first child. I haven't tried to determine if there are two processes as a result of hitting the form but I know from the logs that the module starts cycling through the form data again.
It is probably very sloppy but my problem was that given a username and their file, the file was being opened twice which made parsing a bit tricky. All I want is to open the file once. I am open to more elegant suggestions though :-)
Dp.
On 30 Jul 2004 at 2:41, Tom Schindl wrote:
Hi,
Are you sure that's working as you expected? If I got you right I'm afraid I have to disappoint you but this only works if the second request is handled by the same apache-child as the first one and there's another problem. If you come back one day later and hit the same apache-child which already processed the first request, you won't get anything.
Tom
Dermot Paikkos wrote:
Arnaud,
I have found a way around this. I don't know if your interested but it goes likes something like this:
foreach my $param ($r->param) { if ($param =~ /\busers\b/) { $users{$r->param($param)} = 0; } ....snip...then later
foreach my $key (keys %users) { next if ($users{$key} == 1; $users{$key} = 1; }
The idea being you only work request that haven't been processed yet.
Once you process a request you increment that hash key to 1 and can
avoid using it again. IE still sends the request twice and it is
working with the first request not the second.
Just a thought. Dp.
On 29 Jul 2004 at 16:20, Arnaud Blancher wrote:
Dermot Paikkos a écrit :
Does this mean you have to go an clean up these files later
yes, if you dont want they stay on the disk.
or is this done when the process ends?
maybe you can write a special handle for the directory where you ll write your pdf that delete the pdf when the connection (due to the redirect) will be close by the client (but i'not sure).
I don't want to slow the users down unless I have to.
I think I would like to determine the user-agent and work around the repeating requests....somehow. Do you know how to find out the user- agent when using Apache::Request? I can't see it when I use this object. Thanx. Dp.
~~ Dermot Paikkos * [EMAIL PROTECTED] Network Administrator @ Science Photo Library Phone: 0207 432 1100 * Fax: 0207 286 8668
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
~~ Dermot Paikkos * [EMAIL PROTECTED] Network Administrator @ Science Photo Library Phone: 0207 432 1100 * Fax: 0207 286 8668
Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
