Apache::Session::File hangs
Hi!
The following code hangs after reloading and the try to tie again the
previously created session! WHY?
package Loop;
use strict;
use Apache;
use Apache::Session::File;
use CGI qw(:cgi);
use Devel::Symdump;
use Data::Dumper;
use vars qw(
$id $sID
$lockDir
%session $sessionDir
);
sub handler{
if(defined ($id = param(sID)) -f
/usr/local/httpd/htdocs/action/sessions/$id){
print STDERR found $id :-}\n;
$sID =1;
eval{
tie %session, 'Apache::Session::File', $id,{
Directory = '/usr/local/httpd/htdocs/action/sessions',
LockDirectory = '/usr/local/httpd/htdocs/action/lock'
};
};
}
else{
eval{
tie %session, 'Apache::Session::File', undef,{
Directory = '/usr/local/httpd/htdocs/action/sessions',
LockDirectory = '/usr/local/httpd/htdocs/action/lock'
};
};
$id = $session{_session_id};
}
if($@){print STDERR oops $@\n;}
untie %session;
print STDERR $id redirecting2:
http://$ENV{'HTTP_HOST'}$ENV{'SCRIPT_NAME'}?sID=$id\n;
print redirect http://$ENV{'HTTP_HOST'}$ENV{'SCRIPT_NAME'}?sID=$id;
}
1;
on STDERR I get:
c838622a5e5ec2b39a26c67b6731188f redirecting2:
http://localhost/action/leer.html?sID=c838622a5e5ec2b39a26c67b6731188f
found c838622a5e5ec2b39a26c67b6731188f :-}
my .htaccess :
FilesMatch .*\.html$
SetHandler perl-script
PerlHandler Loop
/FilesMatch
Thanks,
Axel
Re: Apache::Session::File hangs
Axel Huizinga wrote: The following code hangs after reloading and the try to tie again the previously created session! WHY? ... use vars qw( $id $sID $lockDir %session $sessionDir ); The session variable has to go out of scope for the lock to be released. I know it seems like the untie should do it, but try making %session a lexical instead of a global. - Perrin
Anyone ever have Apache::Session::File files getting corrupted?
This is going to be a somewhat preliminary feeler post because we are not yet able to fully describe or recreate the bug we're seeing, but I'm hoping some of you have seen something similar. We use Apache::Session::File as the storage module for our Apache::Session sessions. I have written an object (RMS::Session where RMS is our app) that basically is just a wrapper class for the Apache::Sessions. When I instantiate a new RMS::Session, it goes and ties to the actual Apache::Session, gets a hold of the session hash, populates it's member variables with values from the session hash, and unties/undefs the session hash. Thus we end up with a perl object representing our session with a friendly OO interface for our developers that they are used to, and the real session is freed for use by other requests. Everytime I instantiate a new RMS::Session, I timestamp the Apache::Session and I increment a 'retrievals' variable. Pretty much every request into our app needs to look at the session for something, so the end result is that sessions are being tied and written a lot. In some cases, a user will click into an area of our application that has say three frames, and the content of all three frames will go and look at the session, so three requests for the same session could come in at the same time, so it's probably exercising the locking mechanism fairly well. Here's the basic problem we're seeing...our sessions have a very well defined set of variables in them so the size of the session file is very predictable - in our case, they all are between 320-360 bytes at all times. What seems to be happening is that sometimes (more on this later) the files get written out in a corrupted state, and I've noticed it's a well-defined corruption to where the session file will shrink to a size of either 150 bytes or 63 bytes. Once this happens, the session is corrupted, in that I can no longer successfully retrieve any information from it. The session is still there, but the contents have been completely garbled. Unfortunately, it's neither predictable nor easy to reproduce. First, it only happens occasionally. we haven't yet found one set of actions that we can take and cause it to happen every time. One test we use to demonstrate it is to simply log in and out several times. Sometimes, 7 or 8 logins will go by without incident, and then the 9th will cause a corrupted session. Other times, 10 logins in a row will lead to a corrupted session. Secondly, it happens far more frequently on our production server than our development server (same exact code and versions of perl and all modules). I've begun to suspect that perhaps it only happens after a certain period of latency. Since our production server has a lot more data in it's database, operations tend to take much longer than they would during development. Perhaps this means that there's more opportunity in production for a request to ask for a session that's still held/locked by another child request. Like I said, it's still very preliminary. Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? We're just trying to narrow down the possibilities since it's been two days of four engineers trying to come up with any sort of recipe for reliable reproduction or pattern to the bug with no luck so far. Thanks, Fran
Re: Anyone ever have Apache::Session::File files getting corrupted?
I think most people don't use Apache::Session::File in production. It's
more of a testing thing. In your situation, you would probably get
great performance from MLDBM::Sync with SDBM_File. I'd suggest trying
that if you can't determine the cause of the Apache::Session::File issues.
Not to say that the other options won't work, but we're using
Apache::Session::File in production with no issues, handling in excess of
30 hits per second. It works fine, and it's easy to keep old session
files cleaned up with a simple cron job that finds and deletes session
files older than some limit.
During development we also noticed race conditions with near-simultaneous
pageloads into framesets. Try the 'Transaction' option when you tie to
the session - here is how that part of our mod_perl handler looks:
# NOTE:
# At this point, $session_id is either set to some
# value from a cookie (for an existing session)
# or it is undef
my %session = ();
my $opts = {
Directory = $SESSIONFILEROOT/$site,
LockDirectory = $SESSIONLOCKROOT/$site,
Transaction = 1,
};
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
if ( $@ ) {
# Session tie failed for some reason. If it was because
# an existing session is invalid, create a new session:
if ( $@ =~ /^Object does not exist in the data store/ ) {
$session_id = undef;
eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
};
}
if ( $@ ) {
# Totally failed to create the session - bail out:
$r-log_error( Tie failed: $@);
return SERVER_ERROR;
}
}
HTH,
Larry Leszczynski
[EMAIL PROTECTED]
Re: Anyone ever have Apache::Session::File files getting corrupted?
[EMAIL PROTECTED] wrote: Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? I think most people don't use Apache::Session::File in production. It's more of a testing thing. In your situation, you would probably get great performance from MLDBM::Sync with SDBM_File. I'd suggest trying that if you can't determine the cause of the Apache::Session::File issues. - Perrin
locking bug in Apache::Session::File
I've been told this is the place to send questions related to apache perl
modules.
I believe I have discovered a locking bug in Apache::Session::File.
The following code should retrieve an existing session from the file system
and place an exclusive lock on the session file:
my $locking_args = { 'Directory' = '/tmp/sessions_dir',
'LockDirectory' = '/tmp/sessions_lock_dir',
'Transaction' = '1' };
tie(%session, 'Apache::Session::File', $session_id, $locking_args);
The 'locking_args' hash is used to pass parameters to the locking object
contained by the session object. According to the Apache::Session
documentation any true value of Transaction should force the object to
exclusively lock the session file. Unfortunately this does not appear to
work (at least not all the time).
Looking in the TIEHASH I think I've discovered the reason. The session
uses a locking object. In this case the locking object is
Apache::Session::Lock::File. This object has two methods which acquire
locks, aptly named acquire_read_lock and acquire_write_lock. The first
method uses flock to acquire a non-exclusive lock. The second method uses
flock to acquire an exclusive lock. TIEHASH checks the value of
'Transaction' and calls acquire_write_lock if the value is true. It then
calls a method named restore. It does this regardless of the value of
'Transaction'. The restore method calls acquire_read_lock. Again it does
this without examining the value of 'Transaction'.
Now according to the flock man page if a process requests a lock on a file
it already has locked, then the new lock will replace the old one. Thus
requesting a non-exclusive lock on file which the process already has an
exclusive lock for will cause the non-exclusive lock to replace the
exclusive one.
The call to acquire_read_lock in the restore method wipes out the exclusive
lock on the session file. This makes it impossible to maintain
transactional consistency with Apache::Session::File.
I was wondering if anyone else out there has run into this problem. Is
there a fix available? My version of Apache::Session is 1.54 which is the
newest version that I see on CPAN. Is there another version out there that
fixes this problem or should I bring this up with the author?
Apache::Session::File and free memory weirdness
Hi All - I'm running Apache, mod_perl and HTML::Mason on Solaris 2.6, and using Apache::Session::File for session management. I've been monitoring free memory as reported by top, and I'm seeing some behavior that is totally baffling me. (If you're interested, there's a graph at: http://www.furph.com/graph.png) Here's the scenario: Around 6 AM, when things are relatively quiet, the graph shows about 1.3GB free memory (out of 4GB total). As traffic picks up during the course of the day, free memory drops to about 300MB by 3 or 4 PM. So far so good, no big surprise - there's a lot more httpd processes running so you'd expect more memory in use. Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? Odd thing #2: (This part seems most bizarre to me.) At 5:15 AM, we run a Perl script that finds and deletes Apache::Session::File session and lock files that are older than 28 days. Usually there are about 50,000 old files that get deleted out of about 2,300,000 total. Almost immediately, free memory on the machine jumps back up to 1.3GB. What's up with that? If I run the script during the middle of the day, when things are busier, I still see the free memory jump up although not all the way to 1.3GB - maybe to 800MB or so. Because of the rate the httpd children cycle, I don't think it's possible any of them could be holding open filehandles to session files that haven't changed for 28 days. Is there something weird about the way top reports free memory? The numbers I get seem consistent with the free column from vmstat. Why would deleting a bunch of files free up 1GB of memory? Any ideas or explanations would be much appreciated! Thanks! Larry Leszczynski [EMAIL PROTECTED]
Re: Apache::Session::File and free memory weirdness
Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. Odd thing #2: (This part seems most bizarre to me.) At 5:15 AM, we run a Perl script that finds and deletes Apache::Session::File session and lock files that are older than 28 days. Usually there are about 50,000 old files that get deleted out of about 2,300,000 total. Almost immediately, free memory on the machine jumps back up to 1.3GB. What's up with that? Sounds like you're counting the buffers and cache in your used memory. Depending on what OS you're on, you may want to look at a tool other than top. The memory used for buffers and cache will be available to applications if they need it. - Perrin
Re: Apache::Session::File and free memory weirdness
Perrin Harkins wrote: Odd thing #1: As it gets into evening time, load on the machine drops off and there are fewer httpd children running, but I am not seeing free memory return to that 1.3GB level. At most it comes back up to 400MB or so. I don't think the httpd children are hanging on to memory, because they cycle through pretty quickly - MaxRequestsPerChild is set to 512 and none of the processes are ever more than a couple minutes old when I look in. Is there any reason to think the parent httpd process would hang on to anything? I have noticed that over time the new processes will spawn with less memory shared. I'm not sure exactly why this is, but it does seem to happen. A nightly complete restart of the server will reset things, but you may not have that option. I have noticed this also. I have a theory about its cause, but I haven't had the free time to hack with it yet. My theory is that when the VM subsystem swaps pages of the mod_perl parent process, those pages become forever unshared (even after they return to memory from swap). So I was going to test the mlockall() Linux system call to see if it made a difference. (Search the archives for mlockall). However, I am using the Linux platform - the VM behavior may be totally different on Solaris. If anyone else has some time to play with mlockall() on Linux, I'd like to know the results. It'll be a few more weeks till I get a chance. -Adi
Re: Apache::Session::File
How do i change this locking mechanish of win32?
Am i using the wrong module? From apache::session::* modules
do you know which are supposed to work on win32?
Thanks
Gunther Birznieks wrote:
You need to change the locking mechanism on Win32 to not use IPC. I believe
there are examples for using Flock based locking but am not sure.
If you are using win32 mod_perl, locking is irrelevant anyway because all
requests are serialized through one engine.
At 03:43 PM 2/5/01 +, harilaos wrote:
Hello,
I ma trying to use this module to store persident data on file
on win32 environment.
I use the code:
use Apache;
use Apache::Session::File;
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
print header();
print start_html;
my %global_data;
eval {
tie %global_data, 'Apache::Session::File', 1,
{Directory = '/temp/sessiondata'};
};
if ($@) {
die "Global data is not accessible: $@";
}
print "hello";
print end_html;
I get error in apache logs :
Can't locate IPC/SysV.pm in @INC
do I need the IPC/SysV.pm module?
I have searched the documentation but i don't see a simple clear example
to do this.
Can you help please?
Thanks
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
Apache::Session::File
Hello,
I ma trying to use this module to store persident data on file
on win32 environment.
I use the code:
use Apache;
use Apache::Session::File;
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
print header();
print start_html;
my %global_data;
eval {
tie %global_data, 'Apache::Session::File', 1,
{Directory = '/temp/sessiondata'};
};
if ($@) {
die "Global data is not accessible: $@";
}
print "hello";
print end_html;
I get error in apache logs :
Can't locate IPC/SysV.pm in @INC
do I need the IPC/SysV.pm module?
I have searched the documentation but i don't see a simple clear example
to do this.
Can you help please?
Thanks
Re: Apache::Session::File
You need to change the locking mechanism on Win32 to not use IPC. I believe
there are examples for using Flock based locking but am not sure.
If you are using win32 mod_perl, locking is irrelevant anyway because all
requests are serialized through one engine.
At 03:43 PM 2/5/01 +, harilaos wrote:
Hello,
I ma trying to use this module to store persident data on file
on win32 environment.
I use the code:
use Apache;
use Apache::Session::File;
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
print header();
print start_html;
my %global_data;
eval {
tie %global_data, 'Apache::Session::File', 1,
{Directory = '/temp/sessiondata'};
};
if ($@) {
die "Global data is not accessible: $@";
}
print "hello";
print end_html;
I get error in apache logs :
Can't locate IPC/SysV.pm in @INC
do I need the IPC/SysV.pm module?
I have searched the documentation but i don't see a simple clear example
to do this.
Can you help please?
Thanks
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
Apache::Session::File
Anybody know why Apcahe::Session::Lock::File.pm uses lock FILES instead of flocking the file? It seems to be causing problems with rapdifre access... o _ /|/ | Jerrad Pierce \ | __|_ _| /||/ http://pthbb.org . | _| | \|| _.-~-._.-~-._.-~-._@" _|\_|___|___|
RE: Apache::Session::File
My bad, it does seem to be using flock, but it still seems to be the consistent point of failure.. and I am untieing immediately after use o _ /|/ | Jerrad Pierce \ | __|_ _| /||/ http://pthbb.org . | _| | \|| _.-~-._.-~-._.-~-._@" _|\_|___|___| -Original Message- From: Jerrad Pierce [mailto:[EMAIL PROTECTED]] Sent: Friday, June 02, 2000 12:43 To: '[EMAIL PROTECTED]' Subject: Apache::Session::File Anybody know why Apcahe::Session::Lock::File.pm uses lock FILES instead of flocking the file? It seems to be causing problems with rapdifre access... o _ /|/ | Jerrad Pierce \ | __|_ _| /||/ http://pthbb.org . | _| | \|| _.-~-._.-~-._.-~-._@" _|\_|___|___|
Modifying of Apache::Session File
Hi, We've got an application where on initial login we're creating the session file. Subsequently, we want to add more hash values into this session file. Immediately after creation if we add values to the session file, these values get stored. After a few pages we tried to modify the existing session file, by First, tie-ing the values to a session hash Second, Modifying the session hash. At the point of modifying the session, the program just hangs waits indefintely. Can anybody help us out with this problem. Murali Differentiated Software Solutions Pvt. Ltd., 176, Gr. Floor, 6th Main 2nd Block RT Nagar Bangalore - 560 032 India Ph: 91 80 3431470 email : diffs+AEA-vsnl.com http://www.diffs-india.com
Re: Modifying of Apache::Session File
On Wed, 31 May 2000, Differentiated Software Solutions Pvt. Ltd. wrote: Hi, We've got an application where on initial login we're creating the session file. Subsequently, we want to add more hash values into this session file. Immediately after creation if we add values to the session file, these values get stored. After a few pages we tried to modify the existing session file, by First, tie-ing the values to a session hash Second, Modifying the session hash. At the point of modifying the session, the program just hangs waits indefintely. Can anybody help us out with this problem. You must have leaked some session objects, and now you are holding stale locks. It is a frequent problem. If you are using a global for the session object, don't do that. Also don't make a circular reference to the session object. -jwb
Re: Modifying of Apache::Session File
Hi, We've solved the problem. I don't know whether this is the way. We untie every time before we tie again and then change the hash. This seems to work. Is this the correct way of modifying the contents. Our session hash is not global. (Hope session object and hash are the same). Session hash is only local to the functions. We are using a file to store the values. Murali -Original Message- From: Jeffrey W. Baker [EMAIL PROTECTED] To: Differentiated Software Solutions Pvt. Ltd. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 01 June 2000 09:12 Subject: Re: Modifying of Apache::Session File On Wed, 31 May 2000, Differentiated Software Solutions Pvt. Ltd. wrote: Hi, We've got an application where on initial login we're creating the session file. Subsequently, we want to add more hash values into this session file. Immediately after creation if we add values to the session file, these values get stored. After a few pages we tried to modify the existing session file, by First, tie-ing the values to a session hash Second, Modifying the session hash. At the point of modifying the session, the program just hangs waits indefintely. Can anybody help us out with this problem. You must have leaked some session objects, and now you are holding stale locks. It is a frequent problem. If you are using a global for the session object, don't do that. Also don't make a circular reference to the session object. -jwb
problem with Embperl and Apache::Session::File
Folks,
I'm running:
Solaris 2.6
Perl 5.005_03
Apache-Session-1.04
HTML_Embperl-1.2b10
and I'm trying to use Apache::Session::File ... I have this test program:
#!/usr/local/perl5.005_03/perl
use Apache;
use Apache::Session::File;
my $id = 1;
my $opts = { Directory =gt; '/tmp' };
my %session;
tie %session,'Apache::Session::File', $id, $opts;
print Content-type: text/plain\n\n;
if ($session{data} eq '') {
print "first time";
} else {
print "not first time";
}
$session{data} = 'x';
untie(%session);
exit;
and am getting this error message:
Invalid argument at
/usr/local/perl5.005_03/lib/site_perl/5.005/Apache/Session/SysVSemaphoreLocker.pm line
46.
Anyone know why this is happening? Thanks for your help,
Dave Saunders
[EMAIL PROTECTED]
Re: problem with Embperl and Apache::Session::File
"David R. Saunders" wrote:
Folks,
I'm running:
Solaris 2.6
Perl 5.005_03
Apache-Session-1.04
HTML_Embperl-1.2b10
and I'm trying to use Apache::Session::File ... I have this test program:
#!/usr/local/perl5.005_03/perl
use Apache;
use Apache::Session::File;
my $id = 1;
my $opts = { Directory =gt; '/tmp' };
my $opts = { Directory = '/tmp', NSems = 16 };
-jwb
