headers
Ken Perl | 1 Aug 2007 12:17
Picon

Re: how to use Apache::DBI

it is really good gotchas and should be included to the
ModPerl::Registry document. thanks a lot.

On 7/31/07, Clinton Gormley <clint <at> traveljury.com> wrote:
> On Tue, 2007-07-31 at 10:09 +0800, Ken Perl wrote:
> > I didn't run it under ModPerl::Registry, is there any risk to use the
> > module? maybe I have to run lots of testing to the existing scripts.
> >
>
>
> There is a risk to using this module, but also a significant benefit:
> speed.
>
> The risks come from:
>
>  - the fact that your script has been written to run one and then exit,
>    so you may have a number of variables that aren't initialised
>    properly - this can produce unexpected errors
>
>  - ModPerl::Registry wraps your script in another sub, which may produce
>    unexpected closures (you would see warnings about variables not
>    remaining shared in your log)
>
> So if you move to using Registry, then you will need to check your
> scripts.
>
> However, using Registry means that your script is loaded and compiled
> once, avoiding this performance hit for subsequent requests - hence it
> runs faster.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Perl | 1 Aug 2007 12:17
Picon

Re: how to use Apache::DBI

ok, I'll try connect_cached too.

On 8/1/07, Perrin Harkins <perrin <at> elem.com> wrote:
> On 7/31/07, Clinton Gormley <clint <at> traveljury.com> wrote:
> > What you could do instead is to use DBI's connect_cached method, which
> > provides similar functionality.  I actually use this instead of
> > Apache::DBI, even when running under mod_perl.
>
> I also use connect_cached in many cases.  Just be aware of what you're
> missing out on, because Apache::DBI does some extra things to protect
> you.
>
> Here are the main differences:
> - Apache::DBI doesn't require code changes.  connect_cached() does.
> - Apache::DBI will avoid caching a connection that you open during
> server startup, so that you don't accidentally try to use the same
> connection in multiple processes (due to forking).
> - Apache::DBI issues an automatic rollback at the end of every
> request, so that if your code dies while it has a transaction going,
> that will be freed before the next request.  (This is only if you open
> your handles with AutoCommit off though.)
>
> Hmm, maybe this should be in the Apache::DBI documentation.
>
> - Perrin
>

--

-- 
perl -e 'print unpack(u,"62V5N\"FME;G\!E<FQ`9VUA:6PN8V]M\"\ <at> ``
")'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Hay | 2 Aug 2007 16:34
Favicon

Using bytes_sent in mod_perl2

I'm in the process of converting some old software from mod_perl1 to
mod_perl2, and I'm finding that $r->bytes_sent() doesn't work as it used
to.

The code is written in a very out-moded style: it is compatible with
mod_cgi, runs via ModPerl::Registry (formerly Apache::Registry), and
produces all its output via explicit print() statements scattered left,
right and centre, including a print() statement to send the response
headers. An error-handling subroutine calls $r->bytes_sent() to find out
if anything has been sent yet, so that it knows whether or not it needs
to send response headers before sending an error page (it could be
invoked either before or after the headers have been sent in the normal
course of events).

This works fine under mod_perl1, but under mod_perl2 I find that the
error-handler always emits response headers itself (i.e. it always
thinks that nothing has been sent yet). Therefore, in those cases where
response headers have already been sent, I now have a second set being
sent, which the user ends up seeing in the web browser. The code in
question is simply:

unless (exists $ENV{MOD_PERL}
		? Apache2::RequestUtil->request()->bytes_sent()
		: tell STDOUT)
{
#... send response headers
}
#... send error page

There is a suggestion in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Geoffrey Young | 2 Aug 2007 17:04
Favicon

Re: Using bytes_sent in mod_perl2


Steve Hay wrote:
> I'm in the process of converting some old software from mod_perl1 to
> mod_perl2, and I'm finding that $r->bytes_sent() doesn't work as it used
> to.

yeah.  IIRC the issue is that now we have filters, so in order to
actually calculate bytes_sent() the filters need to run in their entirety.

> 
> The code is written in a very out-moded style: it is compatible with
> mod_cgi, runs via ModPerl::Registry (formerly Apache::Registry), and
> produces all its output via explicit print() statements scattered left,
> right and centre, including a print() statement to send the response
> headers. An error-handling subroutine calls $r->bytes_sent() to find out
> if anything has been sent yet, so that it knows whether or not it needs
> to send response headers before sending an error page (it could be
> invoked either before or after the headers have been sent in the normal
> course of events).
> 
> This works fine under mod_perl1, but under mod_perl2 I find that the
> error-handler always emits response headers itself (i.e. it always
> thinks that nothing has been sent yet). Therefore, in those cases where
> response headers have already been sent, I now have a second set being
> sent, which the user ends up seeing in the web browser. The code in
> question is simply:
> 
> unless (exists $ENV{MOD_PERL}
> 		? Apache2::RequestUtil->request()->bytes_sent()
> 		: tell STDOUT)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carl Johnstone | 2 Aug 2007 17:07
Picon

reverse proxy/logging problem

Hi,

I've got a two-apache reverse proxy setup, split over two hosts.

The problem I've got is that I'd like to put the user_id in the access logs 
so that our log analysis software can make use of it.

Setting apache->user correctly logs the user at the back-end however the IP 
addresses are wrong, being the internal address of the front-end proxy. Also 
requests dealt with purely at the front-end aren't logged.

Logging at the front-end means all requests are logged with the right IP 
address. Additional bonuses for me are that those servers are less loaded, 
and I'd be able to turn off logging at the back-end. However the user_id 
isn't available.

Is there any easy way to pass the user_id from the back-end in such a way 
the front-end could log it? Or is there another option?

Carl
Permalink | Reply | 2 comments |
headers
Brian Reichert | 2 Aug 2007 17:46

Re: mod_perl2 and SDBM-tied hashes

On Sun, Jul 29, 2007 at 01:49:56PM -0700, Perrin Harkins wrote:
> The dbm implementation you're using will not always write everything
> to disk until you untie it.  To make this transparent, you can use
> MLDBM::Sync, which unties and reties on every request.  This is
> necessary for read/write sharing on all dbms except BerkeleyDB.

Interesting; thanks for the pointer....

> - Perrin

--

-- 
Brian Reichert				<reichert <at> numachi.com>
55 Crystal Ave. #286			Daytime number: (603) 434-6842
Derry NH 03038-1725 USA			BSD admin/developer at large
Permalink | Reply | 0 comments |
headers
Torsten Foertsch | 2 Aug 2007 17:49
Picon
Gravatar

Re: reverse proxy/logging problem

On Thursday 02 August 2007 17:07, Carl Johnstone wrote:
> The problem I've got is that I'd like to put the user_id in the access logs
> so that our log analysis software can make use of it.
>
> Setting apache->user correctly logs the user at the back-end however the IP
> addresses are wrong, being the internal address of the front-end proxy.
> Also requests dealt with purely at the front-end aren't logged.
>
> Logging at the front-end means all requests are logged with the right IP
> address. Additional bonuses for me are that those servers are less loaded,
> and I'd be able to turn off logging at the back-end. However the user_id
> isn't available.
>
> Is there any easy way to pass the user_id from the back-end in such a way
> the front-end could log it? Or is there another option?

I'd try to put the user_id in a X-... output header on the backend and log it 
as "%{X-...}o" on the frontend. Maybe you can even use mod_headers to remove 
the header before it reaches the browser.

Torsten
Permalink | Reply | 0 comments |
headers
Brian Reichert | 2 Aug 2007 17:56

Re: mod_perl2 and SDBM-tied hashes

On Sun, Jul 29, 2007 at 03:42:19PM -0400, Jonathan Vanasco wrote:
> any reason why you're using sdbm ?  you might be better off with bdb,  
> since it has that shared memory cache feature.

My initial experiements worked with SDBM, so I ran with it.  :)  I
suppose I could re-rest with DB_File, if that's what you're referring
to...

> you generally don't want to use worker under modperl, and you  
> generlaly do want to use prefork.

So I had supposed.

> The RedHat RPMs tend to be outdated,  especially for modperl.  You're  
> often best suited building apache and modperl from source.

That I know, but I'm trying to limit the set of RPMs I'm building
interally (we have an internal distribution model that entirely
RPM-based.)

--

-- 
Brian Reichert				<reichert <at> numachi.com>
55 Crystal Ave. #286			Daytime number: (603) 434-6842
Derry NH 03038-1725 USA			BSD admin/developer at large
Permalink | Reply | 0 comments |
headers
Steve Hay | 2 Aug 2007 19:08
Favicon

RE: Using bytes_sent in mod_perl2

Geoffrey Young wrote:
> Steve Hay wrote:
>> The code is written in a very out-moded style: it is compatible with
>> mod_cgi, runs via ModPerl::Registry (formerly Apache::Registry), and
>> produces all its output via explicit print() statements scattered
>> left, right and centre, including a print() statement to send the
>> response headers. An error-handling subroutine calls
>> $r->bytes_sent() to find out if anything has been sent yet, so that
>> it knows whether or not it needs to send response headers before
>> sending an error page (it could be invoked either before or after
>> the headers have been sent in the normal course of events). 
>> 
>> This works fine under mod_perl1, but under mod_perl2 I find that the
>> error-handler always emits response headers itself (i.e. it always
>> thinks that nothing has been sent yet). Therefore, in those cases
>> where response headers have already been sent, I now have a second
>> set being sent, which the user ends up seeing in the web browser.
>> The code in question is simply: 
>> 
>> unless (exists $ENV{MOD_PERL}
>> 		? Apache2::RequestUtil->request()->bytes_sent()
>> 		: tell STDOUT)
>> {
>> #... send response headers
> 
> since you no longer send response headers in mp2, isn't this all moot?

Did you overlook the fact that I'm running all this through
ModPerl::Registry, or am I overlooking something?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Vanasco | 2 Aug 2007 19:37

Re: reverse proxy/logging problem


On Aug 2, 2007, at 11:07 AM, Carl Johnstone wrote:

> I've got a two-apache reverse proxy setup, split over two hosts.
>
> The problem I've got is that I'd like to put the user_id in the  
> access logs so that our log analysis software can make use of it.
>
> Setting apache->user correctly logs the user at the back-end  
> however the IP addresses are wrong, being the internal address of  
> the front-end proxy. Also requests dealt with purely at the front- 
> end aren't logged.

This should help you outright, or you can pull out code for your own use
	http://search.cpan.org/~jvanasco/Apache2-xForwardedFor-0.04/lib/ 
Apache2/xForwardedFor.pm

> Logging at the front-end means all requests are logged with the  
> right IP address. Additional bonuses for me are that those servers  
> are less loaded, and I'd be able to turn off logging at the back- 
> end. However the user_id isn't available.
>
> Is there any easy way to pass the user_id from the back-end in such  
> a way the front-end could log it? Or is there another option?

you should likely be able to roll your own based on the above.
Permalink | Reply | 0 comments |

Gmane