perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From macke...@animalhead.com
Subject Re: mod_perl2 + fork + DBI = Chaos
Date Tue, 26 Jan 2010 01:03:49 GMT
You made no comment on the links I sent you earlier today.
They had lots of good advice.  Particularly the first one
suggested not forking the Apache process, but using an
ap(1) call to start a process to do the additional processing.

OK, the ap(1) alternative was a bit light on details.

How about the alternative offered by Perrin Hawkins in the
same thread, of using a cleanup handler to do the follow-up
processing rather than a forked process.

 From p. 107 of "mod_per2 User's Guide":

$r->push_handlers(PerlCleanupHandler => \&cleanup);
> print $in->redirect... # to redirect the browser

Now cleanup (which receives $r as its operand) can do
whatever slow stuff you need to, can probably use DBI
without all the pain you have below, and can access the
request to find out what to do.

In some past context you may have learned how to get hold of
a $r to use in these calls, and hopefully you're no longer
scared of $r.  But there does remain the question of whether
a ModPerl::Registry module can do such calls.

Hopefully someone who knows can chime in on this.

If not, for me it would be worth the editing of getting the
module out from under ModPerl::Registry and into the "native
mode" of SetHandler modperl.

Best of luck,
cmac


On Jan 25, 2010, at 1:54 PM, Tosh Cooey wrote:

> Ok, then maybe I need to supply some code here to try and get  
> clarification:
>
> mailfile.pl
> ###########
> use strict;
> ...
> use POSIX;
>
> #gather needed modules and objects
> my $fileOBJ = new MyOBJS::FILE($in->param('id'));
> my $clientOBJ = new ...
> my $userOBJ = new ...
> # All OBJjects have a {DBH} property which is their DB handle
> # I hear I have to disconnect these first, do I have to disconnect  
> ALL?
> $fileOBJ->{DBH}->disconnect;
> $SIG{CHLD} = 'IGNORE';
> my $pid;
> if ($pid = fork) {
> 	warn "Pid = $pid";
> } elsif (defined $pid) {
> 	close(STDOUT);
> 	close(STDIN);
> 	close(STDERR);
>
> 	# chdir to /, stops the process from preventing an unmount
> 	chdir '/' or die "Can't chdir to /: $!";
> 	# dump our STDIN and STDOUT handles
> 	open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
> 	open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!";
> 	# redirect for logging
> 	open STDERR, '>/tmp/stderr' or die "Can't write to /tmp/stderr: $!";
> 	# Prevent locking to apache process
> 	setsid or die "Can't start a new session: $!";
>
> 	# Create file download link email
> 	my $mailSTR = ...
>
> 	# Send the mail possibly to many people
> 	foreach my $person (@people) {
> 		open(MAIL, '|' . &cfg('sendmail_location') . ' -t');
> 		print MAIL $mailSTR;
> 		close(MAIL);
> 	}
>
> 	# Need to recreate the DBI connection on the $fileOBJ I hear
> 	$fileOBJ = new MyOBJS::FILE($in->param('id'));
>
> 	# Do some SQL to update the $fileOBJ status based on mailout
> 	$fileOBJ->sql....
>
> 	# create LOGGING Objects to log stuff
> 	my $logOBJ = new ...
> 	$logOBJ->sql...
>
> 	CORE::exit(0);
> }
>
> print $in->redirect... # For the parent to redirect the browser
>
> # Done.
>
> Is there a glaring mistake in the above?
>
> The parent does no more DB stuff, it just sends a redirect.
>
> This runs under ModPerl::Registry.
>
> I'd like to get at least one thing working tonight, either the  
> forking or the DBI, I'll be happy!
>
> Tosh
>
>
>
> Perrin Harkins wrote:
>> On Mon, Jan 25, 2010 at 3:48 PM, Tosh Cooey <tosh@1200group.com>  
>> wrote:
>>> Thanks Perrin, the forking, my child got a PID of 30033 and then  
>>> afterwards
>>> when I checked the processes (ps) for 30033 I see:
>>>
>>> [apache2] <defunct>
>>>
>>> Is that what's supposed to happen?
>> After you call exit?  No.  It should be gone.  That's a zombie  
>> process.
>>> That PM thread seems to indicate that I must disconnect every  
>>> DBH, not just
>>> the ones that I will use.
>> Either that, or you need to set InactiveDestroy on all of them in the
>> child process.  Otherwise, when the child exits, it messes up all of
>> them for the parent.
>>> Are you also suggesting the use of
>>> Parallel::ForkManager for forks?
>> No.  The DBI stuff is the same with either.
>> - Perrin
>
> -- 
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/


Mime
View raw message