Re: Magic number checking on storable error with Apache::Session::MySQL
Dan McCormick wrote: Hi, I'm running a site with Apache, MySQL, Mason, and Apache::Session::MySQL. I've been sporadically seeing this message in my error log: [Wed Jul 9 20:41:42 2003] [error] Magic number checking on storable string failed at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 364, at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Serialize/Storable.pm line 27 Can anyone provide any clues as to why this might be happening? Is it implying the db data is corrupt? probably most likely unrelated to mod_perl, the error normally happens when you upgrade Storable and you try to read files that were created with older Storable version. perl users list/newsgroups is probably more appropriate for this issue. FYI, a cronjob deletes sessions that are more than 30 minutes old, but creating a session and then manually deleting it did not reproduce this error. Software specs: Apache 1.3.27 mod_perl 1.27 Apache::Session 1.54 MySQL 4.0.13 Thanks, Dan -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins [EMAIL PROTECTED] wrote: If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- md [EMAIL PROTECTED] wrote: Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? Looks like I get that with InnoDB automatically... __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: --- md [EMAIL PROTECTED] wrote: Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? You effectively have that already, since the MySQL locker only locks an individual session. Check the code. Looks like I get that with InnoDB automatically... You can use actual transactions there. Try starting with the Apache::Session::Store::Postgres module and hacking it a bit. There is no module available that was designed for use with Innodb MySQL tables. - Perrin
Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? Is moving to Apache::Session::Flex a good choice (and then we could also change the session table to INNODB), or should I create my own Apache::Session::MySQL-type module by changing Lock = 'Null'? I didn't see much discussion on this in the archives, so if it is there, please point me to the thread... Thanks... -- On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: Regarding Flex, nobody uses it. It is for debugging. If you have a particular variant of Flex that you use all the time (very likely), you can code up a 6-line module to make a real implementation like all the other session modules. Flex is for debugging, period. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
On Tuesday, February 25, 2003, at 11:55 AM, md wrote: We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. I had a similar problem a few months ago with Apache::Session::Postgres. I occasionally had Apache processes hang, and a quick ps aux shows a stalled query on the sessions table. I ended up dropping it for Apache::Session::File. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. I've not seen the problems since I switched to Apache::Session::File, but I would much prefer using the Postgres module, as it complicates my user's installation. Could the MySQL and Pg implementations have the same problem? Cory 'G' Watson http://gcdb.spleck.net
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
md wrote: Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem. Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? It all depends on how much data you put in (lots of data in the session will slow things down) and how fast your database is. At eToys we used a slightly hacked version of Apache::Session::DBI with Oracle and it handled more traffic than most sites will ever see. - Perrin
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins [EMAIL PROTECTED] wrote: It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem. We talked about this, but in our case, I don't believe this will be an issue. Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet. We put almost nothing in the session other than the user id. There are three apps sharing the same session table, and I believe one app may put two or three other things other than the user id (like current page id and affiliate id...both which I should be able to remove someday:)...but never-the-less, very little data in the session. I've gotten most of my sessioning information from this list (and you), so I believe we are session correctly :) If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. That's what I figured and that's what I'm going to do. Thanks again, -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? Thanks, Richard.
Re: Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. What do you think? Thanks, Richard. (I'll go see your reply in a min. Thank you!) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 11:49 AM Subject: Re: Apache::Session::MySQL Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Thank you, Richard. PS I just replied to the PerlMonks reply you did. Thank you. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 12:08 PM Subject: Re: Apache::Session::MySQL Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
At 01:25 PM 12/28/2002 -0600, Richard wrote: So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Richard, Yes,you can still run regular cgi, as with MP you have to explicitly tell (via directives in httpd.conf) which files to process using MP handlers. My guess is if you are going to convert cgi scripts to run under MP, you are going to be iinterested in Apache::Registry. There is probably a ton of good info on apache.org and elsewhere about how to do this exactly. GV
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL
Great, thank you guys! I am trying to first fix my Apache::Session problem before I open a whole new bag of candy :o) Thank you very much for your input, I am grateful! Richard. - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 2:32 PM Subject: Re: Apache::Session::MySQL So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL question regarding lenght of _session_id
On Mon, 18 Dec 2000, Andreas Marienborg wrote: I just can't seem to find any info on how to specify that Apache::Session should create session_id's that are shorter than 32 hex chars? could someone point me in the right direction?? You can use the argument 'IDLength' when using Apache::Session::Generate::MD5 (the default), or you can replace that class with your own class to generate the IDs you desire. See the obscure Apache::Session::Generate::MD5 perldoc. -jwb
Apache::Session::MySQL question regarding lenght of _session_id
I just can't seem to find any info on how to specify that Apache::Session should create session_id's that are shorter than 32 hex chars? could someone point me in the right direction?? thanks in advance Andreas -- Andreas Marienborg +47 92 28 63 82 [EMAIL PROTECTED] www.palle.net
Re: Apache::Session::MySQL question regarding lenght of _session_id
at a time earlier than now, Andreas Marienborg wrote:
I just can't seem to find any info on how to specify that Apache::Session
should create session_id's that are shorter than 32 hex chars? could
someone point me in the right direction??
Just write a module to sub class Apache::Session. Apache::Session::MySQL is
remarkably simple. Here it is:
package Apache::Session::MySQL;
use strict;
use vars qw(@ISA $VERSION);
$VERSION = '1.01';
@ISA = qw(Apache::Session);
use Apache::Session;
use Apache::Session::Lock::MySQL;
use Apache::Session::Store::MySQL;
use Apache::Session::Generate::MD5;
use Apache::Session::Serialize::Storable;
sub populate {
my $self = shift;
$self-{object_store} = new Apache::Session::Store::MySQL $self;
$self-{lock_manager} = new Apache::Session::Lock::MySQL $self;
$self-{generate} = \Apache::Session::Generate::MD5::generate;
$self-{validate} = \Apache::Session::Generate::MD5::validate;
$self-{serialize}= \Apache::Session::Serialize::Storable::serialize;
$self-{unserialize} = \Apache::Session::Serialize::Storable::unserialize;
return $self;
}
1;
You can have any subroutine you want generate id's. Just change the two lines
where generate is set to Apache::Session::Generate::MD5::generate and validate
to Apache::Session::Generate::MD5::validate. For example:
package Apache::Session::MyOwnPackage;
use strict;
use vars qw(@ISA $VERSION);
$VERSION = '1.01';
@ISA = qw(Apache::Session);
use Apache::Session;
use Apache::Session::Lock::MySQL;
use Apache::Session::Store::MySQL;
use Apache::Session::Serialize::Storable;
sub populate {
my $self = shift;
$self-{object_store} = new Apache::Session::Store::MySQL $self;
$self-{lock_manager} = new Apache::Session::Lock::MySQL $self;
$self-{generate} = \generate;
$self-{validate} = \validate;
$self-{serialize}= \Apache::Session::Serialize::Storable::serialize;
$self-{unserialize} = \Apache::Session::Serialize::Storable::unserialize;
return $self;
}
sub generate
{
# some code to generate ids
}
sub validate
{
# some code to validate ids
}
1;
Of course, you'll actually need to write some code to generate and validate
ids. :)
HTH,
Aaron
thanks in advance
Andreas
--
Andreas Marienborg+47 92 28 63 82
[EMAIL PROTECTED] www.palle.net
--
---
Caution! The beverage you are about to enjoy may be hot.
Re: Apache::Session::MySQL question regarding lenght of _session_id
On Mon, 18 Dec 2000, Aaron E. Ross wrote: at a time earlier than now, Andreas Marienborg wrote: I just can't seem to find any info on how to specify that Apache::Session should create session_id's that are shorter than 32 hex chars? could someone point me in the right direction?? Just write a module to sub class Apache::Session. Apache::Session::MySQL is remarkably simple. Here it is: Thanks for pointing this out..however, I found a better way I thought I'd share with the list: The Apache::Session::Generate::MD5 module actually checks if there is an arg called 'IDLength' when it generates the ID...so I just had to add an IDLength = 8 to my initial Session tie, and everything worked nicely from there on :) Thanks for pointing me in the right direction! -- Andreas Marienborg +47 92 28 63 82 [EMAIL PROTECTED] www.palle.net
Apache::Session::MySQL problem
I'm using Apache::Session 1.51 + mysql 3.22.32 +
mod_perl 1.24 + Apache 1.3.11. They work well except
one problem.
The problem is, if an acquired Session ID (from Cookie)
is not stored in the session database, Apache goes like
panic: POPSTACK
Callback called exit.
I know Apache::Session will die "Object does not exist
in the data store" when it can't restore a session from
database. So my script catch that exception with eval
block.
But panic will happen. why ?
httpd.conf --
Files ~ "\.cgi$"
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
#PerlInitHandler Apache::StatINC
#PerlSetVar StatINCDebug On
PerlModule Apache::DBI
/Files
sample.cgi --
use strict;
use Apache;
use Apache::Session::MySQL;
use CGI;
use CGI::Cookie;
my $q = new CGI;
my %session;
eval {
my $r = Apache-request;
my %cookie = CGI::Cookie-parse($r-header_in('Cookie'));
my $sid = $cookie{SID}-value;
tie %session, 'Apache::Session::MySQL', $sid, {
DataSource = "dbi:mysql(RaiseError=1):dbname",
UserName= "user",
Password= "passwd",
LockDataSource = "dbi:mysql(RaiseError=1):dbname",
LockUserName= "user",
LockPassword= "passwd",
};
};
if ($@) {
print $q-header, $@;
}
Any helps?
+-+-+-+-+-+-+-+-+-+-+-
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Apache::Session::MySQL problem
Thu, 20 Jul 2000 14:29:40 -0700 (PDT) "Jeffrey W. Baker" [EMAIL PROTECTED] wrote: The problem is, if an acquired Session ID (from Cookie) is not stored in the session database, Apache goes like panic: POPSTACK Callback called exit. I know Apache::Session will die "Object does not exist in the data store" when it can't restore a session from database. So my script catch that exception with eval block. But panic will happen. why ? Bug in Perl. Upgrade. my perl version is 5.005_03 with FreeBSD 4.0. shoud I update this to perl 5.6.0 ?? +-+-+-+-+-+-+-+-+-+- Tatsuhiko Miyagawa [EMAIL PROTECTED]
