Re: Config::Loader and HTML::StripScripts
On Tuesday 26 June 2007 16:22, Clinton Gormley wrote: > - used to strip XSS scripting from user submitted HTML Ooooh, cool! I haven't found any modules that does that well enough. > - outputs valid HTML (cleans up nesting, context of tags etc) > > - handles the exploits listed at http://ha.ckers.org/xss.html Great! > I hope this helps others, and if anybody has any suggestions, please > feed them back to me Actually, something I would feel would be very useful is if it could return an XML::LibXML::DocumentFragment object. I tend to use XML::LibXML to parse user input and insert in the document, which is then going through some XSLT, and since you've allready parsed stuff, it seems like a waste to parse again. So that's my feature request! :-) Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Memory Usage
On Friday 30 March 2007 14:00, Georg Grabler wrote: > Initially, the apache processes take 42 MB each (i think this should > be mostly shared memory and a lot of preloaded projects, as usual on > a developer machine). If i connect using SOAP, the process jumps up > to 140-150MB, and i just can't think of why this occurs. I can't help too much with the general problem, but how much is shared after time goes by? If a lot is shared, I wouldn't worry too much, but if there is little shared, it would become expensive to scale. Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
On Friday 23 March 2007 14:57, Geoffrey Young wrote: > fwiw, I am unable to reproduce this in either mp1 or mp2 using what I > consider a basic setup. I have also failed to reproduce the problem on 2.0.3 with my setup. Also, we are very liberal on what kind of usernames, and thus what special characters can enter the URI, and in some cases they go through a registry script, and we have not observed any crashes due to this. Best, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
the "User Pressed Stop Button" Case again
Hi all! We're seeing a lot of 500-errors on the backends, they are proxied. The errors we see are that on upload, we get "End of file found", and [Mon Mar 19 01:07:47 2007] [error] [client 213.236.208.101] (70007)The timeout specified has expired: ap_get _brigade failed during prefetch, referer: [snip] [Mon Mar 19 01:07:47 2007] [error] Internal apreq error Does this sound like the old "User Pressed Stop Button" case? In that case, it sounds like we can't really find an elegant solution, right (ref section 6.9 in the modperl book)? But can we at least avoid that it results in a 500? Or is this likely due to something more serious? Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: apache MaxClients and locking up
On Thursday 08 February 2007 17:42, Jonathan Vanasco wrote: > Are you using a 2 sever setup, where mp runs on an alternate port and > something on port 80 (or elsewhere on the LAN) proxies the request > ? If not, try setting that up. That can squeeze out some > performance. You could just have a ton of requests queued because > slow clients are tying up all 13 children. Actually, it is not only there to squeeze out some performance, in my experience it is absolutely essential to do this on a somewhat heavy mod_perl application. So, I'd strongly recommend it, John! And if that doesn't work, you need more RAM! :-) Unless, of course, you max out the CPU, then you need a faster CPU or another box... Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Tiny but bad bug in Apache2::SizeLimit?
Hi all! I just threw in Apache2::SizeLimit on the benchmark system and noticed this: [Thu Nov 16 11:49:03 2006] [error] [client 10.20.21.93] Can't locate object method "shared_cleani" via package "Linux::Smaps::VMA" at /usr/lib/perl5/Apache2/SizeLimit.pm line 113. I haven't really investigated, but it looks to me that shared_cleani is a typo, and I figured it is better that I shout now, just in case 2.0.3 was going out the door... Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Setting MaxClients based on SizeLimit
Dahut!
So, I figured that MaxClients doesn't need to be taken out of thin air,
as it can be computed in a PerlSection once you've set a couple of
Apache2::SizeLimit constants. Which isn't taken out of quite as thin
air themselves. That's beautiful.
But I didn't quite understand from the docs how MaxClients would be set.
First, I tried using
Apache2->httpd_conf("MaxClients $maxclients");
but that didn't work.
Now, based on the formula on page 352 in argh and echo's book, I have
$MaxClients=int(($mem-
$Apache2::SizeLimit::MIN_SHARE_SIZE)/($Apache2::SizeLimit::MAX_PROCESS_SIZE-$Apache2::SizeLimit::MIN_SHARE_SIZE));
where $mem is the actual memory of the box, figured out by
checking /proc/meminfo... It sort of looks like the directives can be
set by just putting a $ in front, but does that work for everything?
Cheers,
Kjetil
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Loading at startup to use shared memory
On Tuesday 07 November 2006 17:17, Torsten Foertsch wrote: > You can directly look at /proc//smaps or use Linux::Smaps. I > don't know what GTop does but I know how /proc//smaps work. > Also, don't do it too often. Reading from /proc//smaps is really > expensive particularly for large process sizes. Wow. Yeah, that's really interesting! So, I started to dive into what this means... I have a lot to learn here... Thanks, I'll be investigating. > Maybe I forgot to say in the docs, /proc//smaps cannot determine > if a page is shared or private if it is out of core (paged out). > Hence to make your measurement accurate you must lock the parent > apache in core or turn off swapping completely. Heh, that's no problem, because our sysadmin insists that swapping sucks, so there is no swap on those boxes... Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Jobs at Opera in Oslo
Hi again! Having seen that people haven't been flamed for posting job openings here, I'd like to point out that we have a few job openings here too. They all involve mod_perl to a lesser or greater extent (most relevant first). They're all physically located in Oslo, Norway, and are full-time positions. For someone looking for job security, I think they are a really good bet. They are Opera Community Developer (pretty much my current position) http://www.opera.com/company/jobs/opening.dml?id=25 System Developer http://www.opera.com/company/jobs/opening.dml?id=26 Quality Assurance Engineer http://www.opera.com/company/jobs/opening.dml?id=24 Junior System Developer http://www.opera.com/company/jobs/opening.dml?id=28 Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Loading at startup to use shared memory
On Monday 06 November 2006 18:08, Torsten Foertsch wrote: > > What operating system is it? If linux see > http://search.cpan.org/~drolsky/Apache-SizeLimit-0.9/lib/Apache/SizeL >imit.pm#linux Yep, it is GNU/Linux, kernel 2.6.17. That's very interesting. I hadn't read up on that, because I thought Apache2::Resource did the same thing, but yeah, I think that is something we want to look into. Also, you're saying that the $Apache2::SizeLimit::HOW_BIG_IS_IT is a better way to assess the shared memory usage then GTop? -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Loading at startup to use shared memory
On Monday 06 November 2006 19:03, Jonathan Vanasco wrote: > i've found the reports of shared/unshared memory to be completely > useless mmm, OK. > the only way i've been able to bench memory usage is to run TOP in a > terminal, and then kill/start apaches with new min_children > settings, to find out the cost of the base memory , + each child. Exactly what numbers are you then reading out of top then? > then make 100-500 requests on each child to test the process growth. OK. > which version of apache are you using? My test system is just upgraded to Ubuntu edgy, while our production servers are Debian Sarge. This translates to 2.0.55 and 2.0.54, respectively. Both systems run mp 2.0.2. > are you using threads? My test system uses mainly defaults, the production servers use preform MPM, which I guess means no. > on my app, which i've extensively profiles, i've got about 110MB of > shared memory, and each child consumes 10-20 mb of unshared memory Wow, that's very nice. -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Loading at startup to use shared memory
Hi all! I'm working on improving the scalability and performance of our app. It is rather bad, and I noticed that not many minutes after restart, the amount of shared memory is down to 10% of the total memory (and I'm at least at 1/3 on my home Axkit::App::TABOO), and besides, it is bad from the start too. Obviously, there is a lot to gain here, since we run a lot of children across many backends. So, I pulled out Stas and Eric's book, which has a chapter about it. That's about mod_perl 1.0, but much of it I presume still is valid. Also, I found an example in http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File which I tried. I have not used the example script of Stas and Eric, but instead insert some GTop stuff in a registry script that loads a small picture from the database. It doesn't really use a lot of the stuff I load at startup. Then I warn the numbers, to find them in the Apache log. Then, I have stared at the numbers with bewilderment. Without any startup.pl file: Size: 59346944 Shared: 6172672 Unshared: 53174272 Then I set the startup.pl, but removed and included different modules, just to see what happens. The results are consistent, though: Size: 76079104 Shared: 5763072 Unshared: 70316032 Size: 78835712 Shared: 5947392 Unshared: 72888320 Size: 73920512 Shared: 4878336 Unshared: 69042176 So, what I see is that consistently, the amount of shared memory goes down when I preload modules at server startup... Weird, huh? It is pretty clear that total memory per child must go up by preloading modules, but the idea was that the shared portion of it should be much greater... I mean, just the code, which is identical per child, should contribute to this... I've been monitoring top as the server runs too, and it seems consistent with these findings, also on other parts of the server. I guess we should rewrite a lot of stuff here, but I was hoping this would be a quick fix for some of our problems, as I think there is a lot in here that would reasonably be in shared memory pages. So, any ideas where I can start to understand why this isn't shared? Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: How to get virtualhost info in mod_perl?
On Thursday 26 October 2006 21:07, Philippe M. Chiasson wrote:
> Terry, Jason wrote:
> > $ENV{‘SERVER_NAME’}
>
> That wold also work.
>
> But in general, I wouldn't recommend using %ENV from within mod_perl,
Can I ask why not? I was of the same opinion, mainly because %ENV is
populated for every request (isn't it?) and so represents an overhead,
but then my colleagues pointed out that if it is there allready, the
penalty has allready been taken, so why not use it? To which I had no
good answer. Perhaps %ENV can be turned off entirely?
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Occasional problems with URI package under mp
On Wednesday 20 September 2006 14:35, Tom Schindl wrote: > @INC = qw(/usr/lib/perl5/Apache2,/usr/share/perl5/,); Errr... I just couldn't imagine that anybody could have done that to our @INC, but I asked around the office and it went like: me: "So, do we have any code that modifies @INC?" cow-orker: "No" me: "Really?" cow-orker: "Well, I removed some legacy stuff a few months ago" me: "Where?" so, it turned out to be a core module, but the @INC was still in there. cow-orker: "Errr, have I committed it?" and the answer was of course no... But now it is, and that was it. So, thanks! Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Occasional problems with URI package under mp
On Tuesday 19 September 2006 16:30, Michael Peters wrote: > > URI.pm location: /usr/lib/perl5/Apache2/URI.pm > > Can't locate object method "new" via package "URI" at [blah] > > That's Apache2::URI, not URI. Duh! I'm blind! :-) > What does the command line version of > that same script print? URI.pm location: /usr/share/perl5/URI.pm which is the right thing, I guess. That is, they are not the same script, since the online version has a lot of stuff around it, but the code does the same thing. > Do you have "/usr/lib/perl5/Apache2" in your > @INC? If so, you shouldn't (I believe that was an old 1.99 thing > before the change into the Apache2 namespace). Huh? Yes, I have that, but that is the correct namespace, isn't it? Also, the code says: package Apache2::URI; [snip] use Apache2::XSLoader (); our $VERSION = '2.02'; so it seems to be the correct version? But yeah, I think it looks like we have the culprit here, but why does it load Apache2::URI when use-ing URI rather than URI...? -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Occasional problems with URI package under mp
On Tuesday 19 September 2006 16:05, Garrett, Philip (MAN-Corporate)
wrote:
> warn "URI.pm location: $INC{'URI.pm'}\n";
>
> If it's different for the failures than it is for the successes, you
> have your culprit.
Hmmm, nope, that was OK...
So, I have
use URI;
warn "URI.pm location: $INC{'URI.pm'}\n";
my $netloc;
eval {
$netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
}; warn $@;
to which I get
URI.pm location: /usr/lib/perl5/Apache2/URI.pm
Can't locate object method "new" via package "URI" at [blah]
Now, there is quite a lot of our internal code around, out of which
quite a few things suck, but still, this really mystifies me...
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Occasional problems with URI package under mp
On Tuesday 19 September 2006 15:26, Garrett, Philip (MAN-Corporate)
wrote:
> Maybe a stupid question, but do you have "use URI" in that program?
Yep! But an entirely appropriate question in this situation. :-)
Actually, the problem was far less reproducible than I first thought...
At some point, I would get this error with
use URI;
use LWP::UserAgent;
my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
my $ua = LWP::UserAgent->new;
warn "foo";
print "Content-Type: text/plain\n\nfoo";
but that works right now...
For a while, I could rearrange the use statements to make it work, but
that now appears to be random...
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Occasional problems with URI package under mp
Hi all!
We've been seeing some really weird things with LWP, but only when
running it on the web server. It works fine when running from the
command line.
For example, doing this:
my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
currently results in a
Can't locate object method "new" via package "URI"
error.
The first suspicion is of course that there exists a different package
URI somewhere in the system, which is only used by the web server, but
I can't find anything. So, I'm totally in the dark here... This email
is a shot in the dark too, but with all the good people here, perhaps
someone might have some light to shed?
Cheers,
Kjetil
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Receiving user input
On Thursday 31 August 2006 17:17, Daniel B. Hemmerich wrote:
> Anyone have a code snippet of a routine that will parse both POST and
> GET user input and place it into a hash?
Using libapreq, how about something like
my %FORM = ();
my $req = Apache2::Request->new($r);
foreach my $name ($req->param) {
next if ($FORM{$name});
my @values = $req->param($name);
$FORM{$name} = [EMAIL PROTECTED];
}
Completely untested, taken from thin air, but you might like to give it
a try.
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: mod perl Apache2::SOAP Segmentation fault
On Tuesday 01 August 2006 16:43, Davood Firoozian wrote: > libapache2-mod-perl2 Debian stable unfortunately has a pre-release version of libapache2-mod-perl2. It is really, really not want you want to work with, so you may have to use backports. You'll find one at http://www.backports.org/ We're using that in production, it works fine. It gets worse if you need libapreq2 and stuff, I'm not aware of any backports of that, so you may need to compile that yourself. -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: urgent help needed
On Thursday 27 July 2006 17:36, Boysenberry Payne wrote: > LoadModule apreq_module /usr/local/apache2/modules/mod_apreq2.so I think this line is probably what you're missing, Philge. -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Slightly OT: mp2 oriented Captcha Module -- anyone interested ?
On Tuesday 06 June 2006 02:09, Jonathan Vanasco wrote: > i'd like to make this cpanable so other modperlers can use it - would > anyone on the list be interested in collaborating with me, and help > make it more standardized and cpanable? i don't have the time/energy > to do that myself. I could do the CPAN bit, however, I wouldn't want the system to be constrained to image CAPTCHAs. Image CAPTCHAs is a Really Bad Thing. Users hate it, they are not really efficient (or that is, either bad for users or easy for computers), extremely bad for accessibility, quite bad on mobile devices, and really, they don't separate man from machine very well, they separate users with certain capabilities from users without those. See also http://www.w3.org/TR/turingtest/ I'm trying to move away from image CAPTCHAs here, but it is not that easy. Anyway, the above also contains some suggestions. Furthermore, the thing with CAPTCHA's is that it is an arms race. That is, if your measures are more expensive than the spammer's counter-measures, you loose. So, there is a big question how much time you are going to spend on it. You can spend a lot of time on research, and come up with something that spammers really can't crack, but I think it would be more useful to be cheap, i.e. realise that this is going to be a game of whack-a-mole and spend a bit of time on an architecture where you can very cheaply implement plugins. So, when a spammer manages to get through your CAPTCHA, you have a new plugin the next day. But yeah, I'd like to cooperate on this, as we need to replace the stuff we have. Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
The evility of $r->status
Hi all! We have a bunch of old scripts that set $r->status explicitly. For handlers, that's deprecated and unnecessary, but I understand that was the usual way to do it in registry scripts in the old days of mp1. What is not clear to me is if this is evil for scripts under mp2. We're seeing some weird behavior sometimes, and this was under my suspicion, but I don't quite know what to do about it (since I usually write handlers myself) and I wouldn't want to get into all that old code... :-) So, is the use of $r->status evil for Registry scripts under mp2, and if so, what should be done to rewrite them? Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Re: Dealing with malformed cookies
On Tuesday 09 May 2006 20:34, Jonathan Vanasco wrote: > On May 9, 2006, at 5:30 AM, Kjetil Kjernsmo wrote: > > First of all, is it the intended behavior that libapreq2 should die > > under these circumstances? > > yes. > > > If yes, are we supposed to deal with this by > > putting each read of a cookie in an eval block? > > yes. OK. > Both are in the docs. I had no idea either a few months ago. Uh, right. I hadn't read that carefully enough. Sorry. We could use better exception handling here... :-) -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
Dealing with malformed cookies
Hi all! We have seen a problem with server errors when getting malformed cookies. The problem has been seen before, we found from googling [1], but it is not clear how we should address this. We are not quite positive about the source of the malformed cookies, (it may have been only test code, it may have been old sins) but it seems like FF is sending them back as they were, while Opera makes an effort to make them valid. :-) The problem then occurs if there is a malformed cookie in the jar, if any cookie is attempted to be read, libapreq2 dies. First of all, is it the intended behavior that libapreq2 should die under these circumstances? If yes, are we supposed to deal with this by putting each read of a cookie in an eval block? I have seen that recent commits have added some error handling behavior. Is this going to be released soon? How would we use the error handling that is introduced? Any other advice as to how we should deal with malformed cookies with libapreq2? [1] http://mail-archives.apache.org/mod_mbox/perl-modperl/200601.mbox/[EMAIL PROTECTED] Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA
[mp2] Patch for Apache2::Resource defaults problem
Hi and a little dahut to all cryptids!
I was trying out the Apache2::Resource module, and decided to try it out
using just the default configuration. All I got was
Can't locate object method "server" via package "Apache2"
at /usr/lib/perl5/Apache2/Resource.pm line 133.
So, I started hacking the source code, putting in Apache2::ServerUtil in
there, and now it works for me. I must admit that my understanding of
mp2 is still superficial and it may not be necessary, and that case,
please clue me in.
If it is indeed a bug, I have made a little patch on the SVN trunk:
Index: lib/Apache2/Resource.pm
===
--- lib/Apache2/Resource.pm (revision 345000)
+++ lib/Apache2/Resource.pm (working copy)
@@ -26,6 +26,8 @@
use Apache2::Const -compile => qw(OK);
+use Apache2::ServerUtil;
+
$Apache2::Resource::VERSION = '1.72';
our $Debug;
@@ -130,7 +132,7 @@
if ($ENV{MOD_PERL}) {
if ($ENV{PERL_RLIMIT_DEFAULTS}) {
-Apache2->server->push_handlers(
+Apache2::ServerUtil->server->push_handlers(
PerlChildInitHandler => \&default_handler);
}
I haven't actually tested the SVN trunk, just with the mp 2.0.1 I run on
my system, but I'm sure you guys can see with a blink if this was
indeed a bug.
BTW, there's a comment in the POD that Linux doesn't support the DATA
limit, but it is in the manpage on my system, and setting it really low
seemed to limit it. I'm really no kernel hacker, but googling shows
that it was discussed in a Linux 2.2 context. So, here's a little diff
to remove that line, if you also find that it is supported:
Index: Resource.pod
===
--- Resource.pod(revision 345000)
+++ Resource.pod(working copy)
@@ -11,7 +11,6 @@
# default is 64 Meg
PerlSetEnv PERL_RLIMIT_DATA 32:48
- # linux does not honor RLIMIT_DATA
# RLIMIT_AS (address space) will work to limit the size of a process
PerlSetEnv PERL_RLIMIT_AS 32:48
I'm not subscribed to the list (sorry for bothering the moderator), so
please CC any replies.
Cheers,
Kjetil
Re: Tied Apache::Session objects in AxKit::XSP::BasicSession
On mandag 20 juni 2005, 20:26, Perrin Harkins wrote:
> > Uh, actually, that's what I did in my first version, as it is the
> > intuitive thing to do, and couldn't get it to do what it should...
> > To me, it looked as if just the hash was passed, not the tied
> > object... Of course, it could be that I did something else entirely
> > wrong
>
> You just need to call tied() on the hash to get the object at any
> time.
Mmm, ok.
> > Since I was going to retrieve this session reference from pnotes
> > maaany times in the code, I created a little sub for it, perhaps
> > that wasn't such a good idea...? But I think it looked as if only
> > the hash was passed allready in there, so I don't think that was
> > the problem... No alarm bells are going off for me here, any for
> > you?
>
> I'm not sure what you're talking about here. Show me the code you're
> referring to.
OK. The whole thing is checked in at
http://svn.kjernsmo.net/AxKit-XSP-BasicSession/trunk/ and will reveal
how confused I am... :-)
Briefly, I think the problem is buried somewhere in the invalidation
code, lets see how it looks right now:
sub invalidate
{
my $self = shift if (_calledAsMethod(@_));
my $r = Apache->request;
#my %session = _session;
my %session = tied %{ $r->pnotes("session") };
warn Dumper(\%session);
warn ref tied %session;
AxKit::Debug(9, "[BSession] Will attempt to invalidate session");
tied(%session)->delete;
untie %session;
undef %session;
#
# Write it back to pnotes
_session(%session);
Apache::AxKit::Plugin::BasicSession::handler($r);
return;
}
It never gets further than tied(%session)->delete; this is how the log
looks:
Reference found where even-sized list expected
at /usr/local/lib/site_perl/AxKit/XSP/BasicSession.pm line 247.
$VAR1 = {
'Apache::Session::Flex=HASH(0x841a004)' => undef
};
Warning: something's wrong
at /usr/local/lib/site_perl/AxKit/XSP/BasicSession.pm line 249.
[Tue Jun 21 23:51:30 2005] [warn] [client 127.0.0.1] [AxKit] [BSession]
Will attempt to invalidate session
[Tue Jun 21 23:51:30 2005] [warn] [client 127.0.0.1] [AxKit] Caught an
exception
[Tue Jun 21 23:51:30 2005] [error] [client 127.0.0.1] [AxKit] [Error]
Can't call method "delete" on an undefined value
at /usr/local/lib/site_perl/AxKit/XSP/BasicSession.pm line 252.
So, at that point, %session isn't what I expect it to be
The above is an attempt to bypass my little function _session, which I
would use to get or set the session hash, since it is something I do a
lot.
It looks like this:
sub _session {
my %session = @_;
my $r = Apache->request;
if (defined(%session)) {
$r->pnotes(session => \%session);
return undef;
} else {
return %{ $r->pnotes("session") };
}
}
It is the last return that interests us now, and I've tried to do
return tied %{ $r->pnotes("session") };
If I take the minimal route and return %{ $r->pnotes("session") }; from
_session and just set my %session = _session;
then Dumper will give:
$VAR1 = {
'_access_time' => 1119392841,
'_session_id' => 'ba3e899edd0e06939a280fca93e3affc',
'_creation_time' => 1119385419
};
which is the correct data, but obviously not tied to anything, so
tied(%session)->delete; fails.
So, this is basically why I tried
$r->pnotes(session => tied %session);
thinking it would help, but clearly not
Was this sufficiently clear...?
Cheers,
Kjetil
--
Kjetil Kjernsmo
Programmer/Astrophysicist/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Tied Apache::Session objects in AxKit::XSP::BasicSession
On Friday 17 June 2005 06:00, Perrin Harkins wrote:
> > I currently assign to pnotes like this:
> > $r->pnotes(session => tied %session);
>
> No, you want the hash, not the object it's tied to:
> $r->pnotes('session' => \%session);
>
> Then use it like this:
> my $session_ref = $r->pnotes('session');
> $session->{'key'} = 'value';
Uh, actually, that's what I did in my first version, as it is the intuitive
thing to do, and couldn't get it to do what it should... To me, it looked as
if just the hash was passed, not the tied object... Of course, it could be
that I did something else entirely wrong
Since I was going to retrieve this session reference from pnotes maaany times
in the code, I created a little sub for it, perhaps that wasn't such a good
idea...? But I think it looked as if only the hash was passed allready in
there, so I don't think that was the problem... No alarm bells are going off
for me here, any for you?
Cheers,
Kjetil
Re: Tied Apache::Session objects in AxKit::XSP::BasicSession
Hi and thanks for the response!
On onsdag 15 juni 2005, 10:06, Perrin Harkins wrote:
> Ideally, I would suggest you stop putting your session in a global.
> That's just asking for trouble.
Yeah, I've had ambitions to do this for a long time, but not really a
way to implement it gracefully.
> If you put it in $r->pnotes() instead,
OK, I have been working a couple of nights now to do this, and have been
making some progress. But I seem to have difficulties with actually
passing the tied hash, that is, making sure I pass the actually tied
object, not just the data hash.
I currently assign to pnotes like this:
$r->pnotes(session => tied %session);
and the Plugin is where this is most important.
Since most "methods" access this in some way, I created a little helper
sub in the XSP:
sub _session {
my %session = @_;
my $r = Apache->request;
if (defined(%session)) {
$r->pnotes(session => tied %session);
return undef;
} else {
return %{ $r->pnotes("session") };
}
}
When I call this, I seem to be getting a big data structure, with the
data, blessed references to the data storage object, etc.
But it is apparently not the tied object nevertheless as I'm
subsequently doing
tied(%session)->delete;
and that stops with an error "Can't call method "delete" on an undefined
value"...
I have tried a few different things, like return tied
%{ $r->pnotes("session") };
but as one can probably guess, I really don't understand this...
The latest version is checked into SVN, and can be seen on the URI in my
initial email.
> you will never have to worry about it persisting and you can
> get rid of the cleanup handler.
Would be nice, but there is some code in it I would have to figure out
how to handle, it would be nice to just drop it if I can.
Cheers,
Kjetil
--
Kjetil Kjernsmo
Programmer/Astrophysicist/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Tied Apache::Session objects in AxKit::XSP::BasicSession
Hi all! I took over maintenance of AxKit::XSP::BasicSession some time ago from Mike Nachbaur, who wrote it. Recently, we have discovered it has some really bad issues. We have discussed the problems in the usual dahut hangouts, but well, the short story is that none of us grok tie-ing well enough to find our way out of this. I therefore turn to you for enlightenment... This module isn't just used by me, so many will be thankful even if you don't hear it... :-) The code in question can be inspected (and check out) in my SVN repository: http://svn.kjernsmo.net/AxKit-XSP-BasicSession/trunk/lib/AxKit/XSP/BasicSession.pm http://svn.kjernsmo.net/AxKit-XSP-BasicSession/trunk/lib/Apache/AxKit/Plugin/BasicSession.pm and on CPAN: http://search.cpan.org/~kjetilk/AxKit-XSP-BasicSession-0.23_3/ Also, I filed a bug against my own package at RT, just so that people would know that there are issues: https://rt.cpan.org/NoAuth/Bug.html?id=12473 The description isn't quite accurate, and I have recently seen DoS problems with it, so this is really nasty... To elaborate on some details from there, things go wrong when we invalidate a session, as the session is supposed to be untied. However, as described in the Camel Book (pp. 395), this can't happen because we still have references to the tied object. The problem is that we don't understand _why_ we have references to the tied object. The two important packages here is an XSP taglib and an AxKit Plugin, each playing different roles, they are the two links above. The %session hash has been implemented as a package global in the Plugin. The Plugin has a handler and a cleanup method. We attempt to untie the session of there are references in the beginning of the handler, and this is where it fails when it goes wrong. If you look at the invalidate "method" in the XSP, you'll see that it tries to invalidate the session by calling delete on the tied object, and then calls the handler again. This is, I think, a necessity, but it raises my suspicions that there are references left by this that I don't see... I think this is where the problem lies buried, but there is a chance it is in other parts of the code, of course. Your eyeballs will be much appreciated. More than anything else, the problem here is that we don't grok ties, so it is a rather general Perl question. Nevertheless, the rest of the herd felt this would be the right forum to ask. Anxiously hoping for enlightenment, Kjetil -- Kjetil Kjernsmo Programmer/Astrophysicist/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Apache::Session::Store::Postgres FOR UPDATE problems [OT]
On tirsdag 03 mai 2005, 00:40, Michael Schout wrote: > Jeffrey W. Baker wrote: > > It is possible that the FOR UPDATE is spurious. It signals to the > > database system that this transaction intends to write that row. > > With PostgreSQL's MVCC transaction isolation system, it's probably > > not necessary and may be causing problems. > > It definately *is* necessary if you want to ensure that only one > process has access to your session data at a time. MVCC will prevent > a second client from WRITING to the same row, but it will not block > it from reading the row. Thank you all for the follow-up! Indeed the problem here is that we're not destroying the object properly. It is the classical untie trap that we're in, described in the Camel Book. However, neither of us has sufficient understanding of the code, and of tied hashes, I suppose, to really track down the issue. There really isn't any $foo = \%session in there, but we're calling the handler from the invalidate method, which is most likely the source of the problem. It sort of works, with a few quirks, with DB_File as backend store, but unsurprisingly, it doesn't with Pg. So, for now, I have filed a bug against my own package, so that at least my users will have a fair chance to understand what's going on: http://rt.cpan.org/NoAuth/Bug.html?id=12473 If anyone wants to have a look, it is certainly appreciated, otherwise, we'll just have to return to it $later. Cheers, Kjetil -- Kjetil Kjernsmo Programmer/Astrophysicist/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Apache::Session::Store::Postgres FOR UPDATE problems
Honored MPs!
I've taken over maintenance of AxKit::XSP::BasicSession from Mike
Nachbaur, but Mike still contributes and we've been discussing some
problems with it over the past few days.
A:X:BS lets Apache::Session do most of its hard work. However, it seems
like no users have ever gotten it to work with a PostgreSQL backend.
I'm trying to address that now.
On the surface, the symptom is that for certain pages, it will just sit
and spin at the $self->{materialize_sth}->execute; call in
Apache::Session::Store::Postgres for exactly two minutes, then time
out, and that makes the rest of the app confused, so most things go
boom...
We've been banging our heads against this problem in #axkit-dahut for a
couple of days now, and I created the following Pg log:
http://paste.husk.org/3133
Then, I realized at had to read up on what "FOR UPDATE" means. It means
that it'll lock and wait around for a subsequent UPDATE.
So, I'm guessing that what happens is that it sits and waits for a
UPDATE that never happens. I tried to remove the FOR UPDATE from the
SQL statement, and it solves the immediate problem. But FOR UPDATE is
something that is used for transactional integrity, and so, it is
probably a Good Thing and there is probably a good reason why it is
there... So, I'm turning to you with the hope that you can clue me in
to how I can live with it. :-)
A:X:BS is now on CPAN, the latest version is 0.23_3 and previous
versions has had some problems, so this is the one I'm working on. I
realized the Pg store would need different defaults than the others,
and I have also been experimenting with the Commit stuff, in case that
meant something. I've been testing with stuff like
# When using Postgres, a different default is needed.
if ($flex_options{'Store'} eq 'Postgres') {
$flex_options{'Commit'} = 1;
$flex_options{'AutoCommit'} = 1;
$flex_options{'Serialize'} = $r->dir_config( $prefix . 'Serialize' ) ||
'Base64'
}
with no effect
I guess it could be that the use we make of Apache::Session is flawed,
that we should call an update somewhere, but it works (apparently) with
the other data stores. It feels like there is something in the
direction of transactions but I can't figure out what... Or, if it
could be somebody else's bug, relieve me of the feeling of being
stupid... :-)
Clues are most welcome!
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
