headers
Stas Bekman | 1 Oct 2003 02:25

Re: Newbie alert Apache::ASP

Brent Atkerson wrote:
> Hello all, I am a newbie to the world of scripting and am pretty sure this is a basic question.  I have
Apache::ASP installed and the samples work great so I know things are working.  So, here is my question:

Brent, please ask Apache::ASP questions at this list:
http://perl.apache.org/maillist/asp.html

Thanks.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas <at> stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
Permalink | Reply | 0 comments |
headers
Matisse Enzer | 1 Oct 2003 03:36

Re: How to attach a hashref or other data to the request object?

Thank you.

This works just fine.

At 3:03 PM -0700 9/29/03, Daisuke Maki wrote:
>Check out $r->pnotes().
>
>    $r->pnotes( OurHash => { foobar => 1 } );
>
>--d
>
>Matisse Enzer wrote:
>
>>Is there an appropriate way in mod_perl 2 for me to take a hashref 
>>and somehow add it to the Apache request object so that Perl code 
>>later in the request handling process can access it, for example 
>>with:
>>     my $hash = $r->{OurHash};
>>or something like that?
>>
>>Specifcally what i am trying to do is to take a hash created using 
>>Apache::Session (a tied hash) and have a reference to that hash be 
>>available in the Apache request object for the rest of the 
>>request's lifetime.

--

-- 
------------------------------------------
Matisse Enzer
Hamilton Partners
707-431-4300 ext. 212 (office)
(Continue reading)

Permalink | Reply | 0 comments |
headers
perl | 1 Oct 2003 05:13

Perl Class destory

under mod_perl, does the module being called in the web that create
classes get cleaned up w/o calling destroy explicitly? That is, if I
create a DBI handler wrapper class, closes the db connection, finish the
code but never call the destroy on explicitly. Or for any Class object?

I'm using DBI not Apache::DBI.

thanks,
-rkl
Permalink | Reply | 1 comment |
headers
Praveen Ray | 1 Oct 2003 05:05

Re: Perl Class destory

It's just like any other perl object..If you keep a reference to your
object in global or package namespace,it's destroy will never be called
since modules under mod_perl are not unloaded unlink cgi.
If your object is lexically scoped,it'll be cleaned upon scope exit.

On Tue, 2003-09-30 at 23:13, perl <at> swanmail.com wrote:
> under mod_perl, does the module being called in the web that create
> classes get cleaned up w/o calling destroy explicitly? That is, if I
> create a DBI handler wrapper class, closes the db connection, finish the
> code but never call the destroy on explicitly. Or for any Class object?
> 
> I'm using DBI not Apache::DBI.
> 
> thanks,
> -rkl
>
Permalink | Reply | 0 comments |
headers
Carl Brewer | 1 Oct 2003 10:54
Picon

mp2: brief success story


Just for the archives, I'm using mp2 (usually fairly recent CVS
pulls) in production on a number of sites I'm hosting on a NetBSD
server.  These include my cycling coaching website : www.aboc.com.au
which uses Template::Toolkit, mp2, my own authentication
stuff (not a handler, yet :) ) and MySQL as a backend.  I also used
it for db-tour.bl.echidna.id.au, also using Template::Toolkit
but with no database stuff.  It's all pretty low traffic, but I've not
had a crash in 4 months, and that's pretty good for development stuff.

Thanks heaps to Stas and the mp community for all your work with mp2 and
answering my clueless questions :)

Carl
Permalink | Reply | 0 comments |
headers
Matthew Hodgson | 1 Oct 2003 20:47

Strange (13)permission denied in 1.28

Hi all,

I just upgraded from Apache 1.27/mod_perl 1.27 to Apache 1.28/mod_perl
1.28 and am noticing some weird behaviour on Apache::Registry scripts -
executing a Registry script ( /webroot/www.domain.com/perl/test.pl ) by
calling a URL such as:

http://www.domain.com/perl/test.pl/movies/image/1234

pops up a message in the error log that:

[Wed Oct 1 14:13:01 2003] [error] [client 217.207.98.119] (13)Permission
denied: access to /movies/images/1234 failed because search permissions
are missing on a component of the path

The script itself seems to run correctly - test.pl is a completely simple
dummy which just prints headers and exits.

Now, /webroot/www.domain.com/movies/ exists, deliberately has permissions
0700 and is owned by root - but why is Apache or Apache::Registry trying
to stat that path at all - and how do I stop it or stop the error
messages?

any help would be gratefully received;

Matthew.

________________________________________________________________
Matthew Hodgson   arathorn <at> theonering.net   Tel: +44 7968 722968
             Arathorn: Co-Sysadmin, TheOneRing.net®
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geoffrey Young | 1 Oct 2003 21:08
Favicon

Re: Strange (13)permission denied in 1.28


Matthew Hodgson wrote:
> Hi all,
> 
> I just upgraded from Apache 1.27/mod_perl 1.27 to Apache 1.28/mod_perl
> 1.28 and am noticing some weird behaviour on Apache::Registry scripts -
> executing a Registry script ( /webroot/www.domain.com/perl/test.pl ) by
> calling a URL such as:
> 
> http://www.domain.com/perl/test.pl/movies/image/1234
> 
> pops up a message in the error log that:
> 
> [Wed Oct 1 14:13:01 2003] [error] [client 217.207.98.119] (13)Permission
> denied: access to /movies/images/1234 failed because search permissions
> are missing on a component of the path
> 
> The script itself seems to run correctly - test.pl is a completely simple
> dummy which just prints headers and exits.
> 
> Now, /webroot/www.domain.com/movies/ exists, deliberately has permissions
> 0700 and is owned by root - but why is Apache or Apache::Registry trying
> to stat that path at all

it's apache that is doing that stat call, and it's doing it because your URL 
has extra path information in it, and that extra path information happens to 
coincide with an existing directory structure.

see httpd_request.c in the apache sources and look for get_path_info.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan McCormick | 1 Oct 2003 21:53

Apache::Session::File locks getting stuck

Hi,

I have an Apache 1.3.27/modperl 1.27 site using HTML::Mason 1.20 with
MasonX::Request::WithApacheSession 0.23 on a Redhat 7.3 system.  The
site gets about 5,000 hits/day.

Each day, a few dozen httpds get stuck waiting for locks on the
Apache::Session files.  An lsof on the Apache pids reports things like
this:

httpd   10956 root   11u   REG        3,2       0   705177
/www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock
httpd   10956 root   22u   REG        3,2       0   705177
/www/.../session_locks/Apache-Session-96d21c169d9c1d5490c04178fca08d8c.lock

and an strace reveals:

flock(11, LOCK_EX

I've set things up per the MasonX::Request::WithApacheSession docs and
sample files, and I'm not doing anything particularly extraordinary with
the sessions.  Anyone have any thoughts on how I might fix the problem?

Thanks,
Dan
Permalink | Reply | 26 comments |
headers
Perrin Harkins | 1 Oct 2003 22:06

Re: Apache::Session::File locks getting stuck

On Wed, 2003-10-01 at 15:53, Dan McCormick wrote:
> Each day, a few dozen httpds get stuck waiting for locks on the
> Apache::Session files.
...
> I've set things up per the MasonX::Request::WithApacheSession docs and
> sample files, and I'm not doing anything particularly extraordinary with
> the sessions.  Anyone have any thoughts on how I might fix the problem?

I suggest you switch to the MySQL storage, and use the NullLocker. 
MySQL updates are atomic, even without the extra locking that
Apache::Session adds.  The file stuff could be atomic in this way too,
but unfortunately it isn't implemented that way.

The really bad thing though is that this may indicate that you have
scoping problems that are preventing your session objects from being
cleaned up.  This would result in lost data (since the updates won't get
written) even if you fix the locking problem.  I suggest you go over the
code where you use the session hash very carefully and make sure it goes
out of scope at the end.

- Perrin
Permalink | Reply | 18 comments |
headers
Matisse Enzer | 1 Oct 2003 22:23

Scope of Apache request object and Apache::Session scoping.

In answer to another question Perrin Harkins <perrin <at> elem.com> wrote:

>  I suggest you go over the code where you use the session hash very
>  carefully and make sure it goes out of scope at the end.

I'm sticking a reference to the session hash in the Apache request object:

    $r->pnotes($auth_name => \%session );

This is under mod_perl 2

I'm doing this in the belief that the request object goes out of 
scope when Apache finishes handling the request, is this correct?

--

-- 
------------------------------------------
Matisse Enzer
Doodlelab Inc.
415-925-5294 ext. 212 (office)
415-225-6703 (mobile)
Permalink | Reply | 15 comments |

Gmane