At 8:41 AM -0700 5/22/02, Doug MacEachern wrote:
>On Wed, 22 May 2002, Dan Wilga wrote:
>
>> Interesting. When I do that, I get the same problem I did when I
>> tried to run with 1.25_01 and 1.26: Apache core dumps. I think I'll
>> have to try compiling it aga
At 6:56 PM -0700 5/21/02, Doug MacEachern wrote:
>On Tue, 21 May 2002, Dan Wilga wrote:
>
>> I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with:
>
>with 1.25, you can also set the PERL_DESTRUCT_LEVEL environment variable
>to 2, ei
d yes it's a DSO. It's compiled with:
USE_APACI=1 SSL_BASE="/usr/local/ssl" DO_HTTPD=1
So I guess the solution is to go to 1.26 or newer; I'll try that
later in the week.
Dan Wilga [EMAIL PROTECTED]
Web Technology Specialist
so my mod_perl code isn't even being run, beyond
initialization. (I use a PerlRequire to load a bunch of libraries at
startup.)
Are there any FAQs that address the reason for such large leakage? Or
is this just an unavoidable problem with graceful restarts?
Dan Wilga
while. So the better approach is not to
"stop" again but, if "start" fails, wait a few seconds and try the
start again.
In general, as mentioned above, the only real reason I've found to
fully stop is to recover lost memory. (OK, there are a few httpd.conf
di
I would also suggest using BerkeleyDB.pm, but with the
DB_INIT_MPOOL|DB_INIT_CDB flags. In this mode, only one writer is
allowed at a time, and Berkeley automatically handles all the locking
and flushing. Just don't forget to use db_close() to close the file
before untie'ing it.
my( $file, $Rhash, $env ) = @_;
my $db_key = tie( %{$Rhash}, 'BerkeleyDB::Btree',
-Flags=>DB_CREATE,
-Filename=>$file,
-Env=>$env );
die "Can't open $file: $! ".$BerkeleyDB::Error.&q
nterface.
Of course, that would avoid the problem, because I wouldn't be using
DB's built-in locking anymore :-) Using tie() means losing the
environment, which is needed for DB's internal locking.
In a production environment with thousands of hits per hour coming in
on multiple t
#x27;m not sure I'll ever get over undef being proper closing
>of a database connection; it seems so synonomous to free([23]). I
>expect something like $db->db_close() or something.)
Agreed!
Dan Wilga [EMAIL PROTECTED]
Web Technology S
env;
return $env;
}
sub open_db {
my( $file, $Rhash, $env ) = @_;
my $db_key = tie( %{$Rhash}, 'BerkeleyDB::Btree',
-Flags=>DB_CREATE,
-Filename=>$file,
-Env=>$env );
die
and DB 4.
This is one of those times I really wish I could go back and edit my
posts :-). Anyone reading this thread will now be seriously confused.
So I'll try Aaron's suggestion of writing it as a handler. Any other
suggestions are welcome.
Dan Wilga
ee if Apache::Registry is partly
>to blame.
Sorry, I figured out that the problem persists even when mod_perl is
completely disabled, so the problem must lie in either Apache or
Berkeley DB. (As a diagnostic, I think I'll try disabling
mod_auth_db.* and mod_ssl, since they both use DB.)
At 1:55 PM -0500 3/21/02, Perrin Harkins wrote:
>Dan Wilga wrote:
>>What surprises me is that all I have to do to introduce the problem
>>is run it under mod_perl. It acts normally when run from the
>>commandline.
>
>Well, let's see, what would be different...
&g
At 1:32 PM -0500 3/21/02, Perrin Harkins wrote:
>Dan Wilga wrote:
>>If I either use DB 3.x or even run this from the commandline
>>(bypassing mod_perl) under DB 4 the problem goes away: only one
>>locker is allocated per loop, and therefore the total number used
v;
return $env;
}
sub open_db {
my( $file, $Rhash, $env ) = @_;
my $db_key = tie( %{$Rhash}, 'BerkeleyDB::Btree',
-Flags=>DB_CREATE,
-Filename=>$file,
-Env=>$env );
die "Can't open $file
15 matches
Mail list logo
