loading mod_perl DSO on a per-virtualhost basis?

[Thomas Corte]

Hello,

I'd like to configure my apache installation (which contains
several virtualhosts) to use mod_perl (compiled as DSO)
only with _some_ of the virtualhosts, but not all of them.

That is, I'd like to put a LoadModule directive into those
 sections which use mod_perl and leave it out
in the other virtualhosts. The benefit (so I hoped) would be
a "small" httpd for the non-mod_perl-virtualhosts and a
bigger one for the others.

>From the apache docs, I now get the information that LoadModule
is only allow in a Server Config context. So it seems that
my initial assumption about the DSO mechanism was too optimistic -
when used in server context, I guess that again all httpd processes have
the full size - or is apache smart enough to drop in the module
only when the first function within it is accessed?

It it possible to get the above functionality with DSOs at all?
If not, what is the real benefit of DSO, besides the ability
to remove and add server functionality without recompiling?

_

Thomas Corte
<[EMAIL PROTECTED]>

Re: loading mod_perl DSO on a per-virtualhost basis?

[Bruno Connelly]

  Thomas> I'd like to configure my apache installation (which contains
  Thomas> several virtualhosts) to use mod_perl (compiled as DSO) only
  Thomas> with _some_ of the virtualhosts, but not all of them.

Apache fork()s children to handle requests, hence they are all exact
copies of the parent process.  Unfortunately, there isn't really a way
to do what you want.

  Thomas> That is, I'd like to put a LoadModule directive into those
  Thomas>  sections which use mod_perl and leave it out
  Thomas> in the other virtualhosts. The benefit (so I hoped) would be
  Thomas> a "small" httpd for the non-mod_perl-virtualhosts and a
  Thomas> bigger one for the others.

A single httpd process could handle requests for many different
vhosts.

You could always run separate Apache instances per vhost.  :-)

--bruno


 Bruno Connelly   <[EMAIL PROTECTED]>
 Interweb Ninjaneer   Whack Productions

Re: loading mod_perl DSO on a per-virtualhost basis?

[Thomas Corte]

Hi,

On Wed, 26 Jan 2000, Bruno Connelly wrote:

> You could always run separate Apache instances per vhost.  :-)

Thanks for your comments.
>From the added ":-)", I derive that this may not
be common practice :)

However, if I'd like to do so, I'd have to split up my httpd.conf
into a part with mod_perl-using-vhosts and a part with the remaining
vhosts and setup 2 startup scripts for 2 separate apache instances,
both listening on port 80 (or 443 for https).

Has anyone ever tried such a setup or used it for a longer period
in a production setup?

_

Thomas Corte
<[EMAIL PROTECTED]>

Re: loading mod_perl DSO on a per-virtualhost basis?

[Bruno Connelly]

  Bruno> You could always run separate Apache instances per vhost.  :-)

  Thomas> From the added ":-)", I derive that this may not be common
  Thomas> practice :)

It's not uncommon, I'm just making the assumption that if you're
worried about resource consumption, this might not your desired
solution.  However, I don't know your setup.  If you'll only be
splitting vhosts between a mod_perl enabled Apache instance and one
that's not, it might not be too bad.  ...assuming the management of
that wouldn't be too much of a headache.

  Thomas> However, if I'd like to do so, I'd have to split up my
  Thomas> httpd.conf into a part with mod_perl-using-vhosts and a part
  Thomas> with the remaining vhosts and setup 2 startup scripts for 2
  Thomas> separate apache instances, both listening on port 80 (or 443
  Thomas> for https).

Yup, it's pretty straight forward.  Given you won't want to bind() to
every interface plumbed on the machine, you'll probably want to put in
a Listen directive per vhost.  Unless you're doing name based
vhost'ing, but you'll still want a single Listen directive per
instance.

  Thomas> Has anyone ever tried such a setup or used it for a longer
  Thomas> period in a production setup?

It should work fine, just keep in mind the extra resources required
for multiple instances (especially with pre-forking).  But again,
splitting one instance into two shouldn't be too nasty.

--bruno


 Bruno Connelly   <[EMAIL PROTECTED]>
 Interweb Ninjaneer   Whack Productions

self url

[Vladimir Ivaschenko]

Hello,

Is there a way to get the URL of the current document in Embperl?
Sort of like $q->self_url in CGI.pm.

Vladimir

Re: self url

[Ilya Obshadko]

Hello Vladimir,

ñðåäà, 26 ÿíâàðÿ 2000 ã., you wrote:

VI> Is there a way to get the URL of the current document in Embperl?
Sort of like $q->>self_url in CGI.pm.

Hmmm. Maybe [- $req_rec->uri -] could help? ($req_rec represents
apache request_rec object in Embperl).

Best regards,
 Ilyamailto:[EMAIL PROTECTED]

Re: PLEASE HELP - ERROR Linking Apache with mod_perl

[G.W. Haywood]

Hi there,

On Thu, 20 Jan 2000, Asghar Nafarieh wrote:

> cd mod_perl-1.21
> perl Makefile.PL PREP_HTTPD=1

I took this from the Guide:

  % cd /usr/src
  % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz
  % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz
  % tar zvxf apache_x.x.x.tar.gz
  % tar zvxf mod_perl-x.xx.tar.gz
  % cd mod_perl-x.xx
  % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \
DO_HTTPD=1 USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1
  % make && make test && make install
  % cd ../apache_x.x.x
  % make install

What happens if you try it this way?

Re: Apache problem with mod_example

[G.W. Haywood]

Hi there,

Mail to your address keeps coming back with fatal errors, so I'm
sending this to the mod_perl List in the hope that we have more luck.

73,
Ged.

On Wed, 26 Jan 2000, Mail Delivery Subsystem wrote:

> The original message was received at Wed, 26 Jan 2000 08:59:57 GMT
> from ged@localhost
> 
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> 
>- Transcript of session follows -
> ... while talking to zmamail03.zma.compaq.com.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 554 Service unavailable; [212.1.144.72] blocked using dul.maps.vix.com
> 554 <[EMAIL PROTECTED]>... Service unavailable
> 

On Tue, 25 Jan 2000, Wang, Pin-Chieh wrote:

> Hi Mr. Haywood,

Please, call me `Ged'.  People are less formal on the Web, I think.

> It turn's out the apache and mod_perl is working after all.

I was sure that Apache was running OK.  That's great!

> when I called 
> //localhost:8080/hello/world everything starts working now.

> But, when I called 
> //localhost:8080/server-info
> I got permission denied. Do you know how can I grant my permission?
> Or just ask for username password?

I took this from your file `Configuration'.  Have you uncommented
the statement and recompiled Apache?  mod_info is required before
you can get server-info.

# AddModule modules/standard/mod_info.o

I also took this from your file `httpd.conf'

# Allow remote server configuration reports, with the URL of
#  http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your_domain.com" to match your domain to enable.
#
#
#SetHandler server-info
#Order deny,allow
#Deny from all
#Allow from .your_domain.com
#

You have to edit this part of the file to give yourself permission
to get server-info.

Hope this helps.

73,
Ged.

RE: self url

[Gerald Richter]

>
> VI> Is there a way to get the URL of the current document in Embperl?
> Sort of like $q->>self_url in CGI.pm.
>
> Hmmm. Maybe [- $req_rec->uri -] could help? ($req_rec represents
> apache request_rec object in Embperl).
>

Or $ENV{SCRIPT_NAME} or $ENV{REQUEST_URI} depending on what you need may
also work

Gerald

Virtual Hosting with Mod_perl?

[David Jourard]

Hi,

I know its a bit off-topic (my apologies) but I thought that for sure 
someone from the list could recommend a web-hosting company that has a 
virtual host account with mod_perl and SQL such as mySQL, mSQL and/or 
Oracle, and possibly with your own apache web server, and of course good 
tech support and performance.

Thanks in advance

David

Re: ANNOUNCE: HTML::Mason 0.8

[Jonathan Swartz]

Good question! I ran a test on my Linux box and it seems to work there, 
anyway. The test repeatedly caused the cache to dump items by loading more 
components that it could handle.  After a few iterations the process size 
maxed out at 6 MB. So it looks like the subroutines do get freed.

If I get around to it at some point I'll cleanup and post the test program.

Jon

At 01:46 PM 1/24/00 -0800, Perrin Harkins wrote:
>On Sun, 23 Jan 2000, Jonathan Swartz wrote:
>>   - New in-memory code cache keeps track of component usage, and
>> discards the most infrequently used components as needed.  You can
>> specify the cache size with interp->max_code_cache_size.
>
>This sounds cool, but does it work, i.e. when you undef a sub reference,
>does the memory really get released and reused?
>- Perrin
> 

Re: Virtual Hosting with Mod_perl?

[Gustav Kristoffer Ek]

On Wed, 26 Jan 2000, David Jourard wrote:

> I know its a bit off-topic (my apologies) but I thought that for sure 
> someone from the list could recommend a web-hosting company that has a 
> virtual host account with mod_perl and SQL such as mySQL, mSQL and/or 
> Oracle, and possibly with your own apache web server, and of course good 
> tech support and performance.

Check out  thats just what you need :)

- gustav


Gustav Kristoffer Ek, Netcetera, Brolæggerstræde 4, 1211 København K
Telefon +45 33 14 70 00 / +45 20 40 00 05 - Faximile +45 33 14 62 00
Design, Webhotel, Mailhotel, UUCP & mod_perl http://www.netcetera.dk

Re: loading mod_perl DSO on a per-virtualhost basis?

[Kees Vonk 7249 24549]

> However, if I'd like to do so, I'd have to split up my httpd.conf
> into a part with mod_perl-using-vhosts and a part with the remaining
> vhosts and setup 2 startup scripts for 2 separate apache instances,
> both listening on port 80 (or 443 for https).


I think you might find the answer to this in the performace tuning 
section of the mod_perl guide:


http://perl.apache.org/guide


I haven't got the full url handy.


Kees

httpsd with my content handler immediately dumps core- likely causes?

[John Walker]

Hi,

I've written an Apache perl module. The module is supposed to look at
the request, and do some DBI selects in an MySQL table, then display
them with HTML::Template. There were initially some issues with scoping,
I hacked through these and eventually get the module to compile without
all the errors that cause the server not to start. 

I've got PerlModule Apache::DBI in my httpd.conf (dev.conf) and I open a
handle to my database before the sub handler {...}.

Now I get only:

[root@melanie /root]# httpsd -X -f /etc/httpd/conf/dev.conf
[Wed Jan 26 10:28:38 2000] [warn] Loaded DSO modules/libperl.so uses
plain Apache 1.3 API, this module might crash under EAPI! (plea
e it with -DEAPI)
Segmentation fault (core dumped)
[root@melanie /root]#

For the record, RedHat's response to the above warning seems to be "Well
it only matters if you're using SSL calls, and you're not, so go to
hell." ... This from a RedHat systems engineer:

>It is a warning, not an error.  You may ignore it.
>It simply means the modules were compiled for a non-SSL-enabled version
>of Apache.  If the modules do not use any SSL functionality, there will
>be no problem.

Whatever, I guess I have take their word for it (or roll my own with
Open SSL which I really can't spare the time to fight with.) Anyway,
some simpler early test versions of the module (before adding the DBI
and HTML::Template stuff) worked, so I THINK mod_perl is OK. There are
some registry scripts running against the same httpsd and mod_perl to
support this assertion.

Nothing is really showing up in the logs (the warning does, nothing
else), I'm wondering if this rings a bell with anyone. 

Perhaps someone could point me to a clearer explanation of Apache::DBI
persistent connections etc... 

I'm still a bit mystified as to the difference for scoping and name
spaces between scripts (modules) that are handlers and scripts that run
under Apache::Registry. I have read Stas's section on this AND man
APache::DBI AND perldoc DBI AND Jeff Baker's thing. Unfortunately they
didn't clear up my confuson. For various reasons (aparently including
masocisim ) I am trying to write my own handler.

Thanks,
John Walker

Re: [ID 20000118.004] DynaLoader doesn't dlclose XS code on interpreter

[Daniel Jacobowitz]

On Wed, Jan 26, 2000 at 04:06:29PM +, Alan Burlison wrote:
> Gurusamy Sarathy wrote:
> 
> > Scheduling dlclose()s using call_atexit() ought to work.  I'm going
> > to let the interested parties test that and send me a patch.
> 
> Is anyone up for this?  I'm in the US this week, so I'm not able to
> contribute much (plus I'd probably just break something ;-)  Gurusamay,
> do you have a timescale for when you need this?

I'll try to do it this weekend, or else if I get bored during
LinuxWorld Expo :)

Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/

problem with variables sticking.

[Etienne Pelaprat]

Hi,

this is a huge problem.  I have a module written a module with a form 
on it, and for some reason or another if one user fills out the form 
and presses the submit button (doing its stuff), and then another 
different user happens to access that same module to display the same 
form at around the same time the first user presses submit, the form 
loads with the values that the first user put into the fields.  Does 
any one have any idea how this could possibly be happening?  It's only 
happening with mod_perl modules, never happened with my perl 
scripts

Thanks,

Etienne

numerous segv's, bus errors

[Steven Parkes]

We've been getting many segv's and bus errors on apache processes since
adding modperl.  Env: Apache 1.3.11 (though we had the same thing
under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00.

At first most of the failures were coming within visit() during what looks
to be clean up of children.  PerlFreshRestart is Off.  I added
PerlSetEnv PERL_DESTRUCT_LEVEL -1
and that seemed to get rid of many of those though this seems like a less
than optimal solution and I'd like to better understand what the real
issue is here.

Moreover, we still see a number of failures.  Many seem to occur in __errno.

(gdb) bt
#0  0xc01ecb88 in kill () from /usr/lib/libc.2
#1  0x769c8 in sig_coredump () from /usr/local/alpha/apache/bin/httpd
#2  
#3  0xc0179214 in __errno () from /usr/lib/libc.2
#4  0xc01751bc in free () from /usr/lib/libc.2
#5  0x10013c in Perl_safefree () from /usr/local/alpha/apache/bin/httpd
#6  0x112248 in Perl_sv_clear () from /usr/local/alpha/apache/bin/httpd
#7  0x112478 in Perl_sv_free () from /usr/local/alpha/apache/bin/httpd
#8  0x10b71c in Perl_av_clear () from /usr/local/alpha/apache/bin/httpd
#9  0x118d18 in Perl_leave_scope () from /usr/local/alpha/apache/bin/httpd
#10 0x116b3c in Perl_pop_scope () from /usr/local/alpha/apache/bin/httpd
#11 0x11e734 in Perl_pp_return () from /usr/local/alpha/apache/bin/httpd
#12 0x12fa18 in Perl_runops_standard () from /usr/local/alpha/apache/bin/httpd
#13 0xd9904 in perl_call_sv () from /usr/local/alpha/apache/bin/httpd
#14 0x3c5d8 in perl_call_handler () from /usr/local/alpha/apache/bin/httpd
#15 0x3bbe0 in perl_run_stacked_handlers () from /usr/local/alpha/apache/bin/httpd
#16 0x3a320 in perl_handler () from /usr/local/alpha/apache/bin/httpd
#17 0x647ac in ap_invoke_handler () from /usr/local/alpha/apache/bin/httpd
#18 0x89404 in process_request_internal () from /usr/local/alpha/apache/bin/httpd
#19 0x894f4 in ap_process_request () from /usr/local/alpha/apache/bin/httpd
#20 0x79c38 in child_main () from /usr/local/alpha/apache/bin/httpd
#21 0x7a1cc in make_child () from /usr/local/alpha/apache/bin/httpd
#22 0x7a6ec in perform_idle_server_maintenance () from 
/usr/local/alpha/apache/bin/httpd
#23 0x7b0c4 in standalone_main () from /usr/local/alpha/apache/bin/httpd
#24 0x7be48 in main () from /usr/local/alpha/apache/bin/httpd

This is a signficant concern for us, both understanding why modperl cores
at all and why it still happening in the current configuration.

If anyone can shed any light on this, I'd appreciate it.

Re: loading mod_perl DSO on a per-virtualhost basis?

[G.W. Haywood]

Hi Thomas,

On Wed, 26 Jan 2000, James G Smith wrote:
> Thomas Corte <[EMAIL PROTECTED]> wrote:
>>So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect
>>to decrease top's values above significantly?
>
> I don't think so.  My understanding of DSOs in Apache was to allow
> inclusion of code without recompiling the whole thing.  This allows
> for third-party proprietary modules.  The DSOs can, in general,
> share code across binaries, not processes.  All processes sharing a
> binary don't have separate copies of the binary, or shouldn't.
> However static libraries cannot be shared between binaries.  Only
> DSOs.  Your biggest savings could come from making the perl core a
> DSO so the perl binary and Apache share the same core perl
> interpreter code.

James is quite right, but I'm told that even making the perl core a
DSO won't give the savings that I think you are hoping for.

In a mod_perl box, as far as memory consumption is concerned, the
processes of concern are usually the Apache children.  They are fairly
big, and there can be a lot of them.  Because of the way that Apache
tries to preempt incoming requests by pre-forking a pool of children
`just in case', you may not always know how many!  They share a good
chunk of their memory when they are forked, but then as a result of
copy-on-write (two or more processes share a page of memory, one wants
to change it, the others don't, so a copy has to be made just for that
process) the memory gradually (or otherwise) becomes unshared.  When
they grab some memory to store a large object, the children have a
habit of hanging on to it until they die.  In addition there have been
memory leakage and similar problems which have sometimes caused the
Apache children to do antisocial things like growing without bound and
refusing to die.  Some of these problems are being dealt with as new
releases come out and I'm sure that a lot of us have high hopes for
mod_perl 1.22.

Running a second server (a `proxy', not mod_perl enabled, and which
listens normally on port 80 but always on a _different_ port from the
mod_perl enabled server) to serve static documents, tweaking the
server configuration variables such as MaxRequestsPerChild to limit
child growth, the use of modules designed to limit the processes'
resource consumption, and faster networks, clients and servers can all
offer partial solutions, but I feel that memory footprint is going to
remain an issue with mod_perl until memory is much cheaper per byte
(happening as we write) or until Doug and friends make it use less, or
until something unthinkable happens - like the technology becoming
obsolete overnight because of a breakthrough elsewhere.

In the meantime, some people are using Gigabytes of RAM to cope with
their mod_perl children.

I hope this isn't too depressing:)

73,
Ged.

Re: httpsd with my content handler immediately dumps core- likelycauses?

[Jeffrey W. Baker]

John Walker wrote:
> 
> Hi,
> 
> I've written an Apache perl module. The module is supposed to look at
> the request, and do some DBI selects in an MySQL table, then display
> them with HTML::Template. There were initially some issues with scoping,
> I hacked through these and eventually get the module to compile without
> all the errors that cause the server not to start.
> 
> I've got PerlModule Apache::DBI in my httpd.conf (dev.conf) and I open a
> handle to my database before the sub handler {...}.
> 
> Now I get only:
> 
> [root@melanie /root]# httpsd -X -f /etc/httpd/conf/dev.conf
> [Wed Jan 26 10:28:38 2000] [warn] Loaded DSO modules/libperl.so uses
> plain Apache 1.3 API, this module might crash under EAPI! (plea
> e it with -DEAPI)
> Segmentation fault (core dumped)
> [root@melanie /root]#
> 
> For the record, RedHat's response to the above warning seems to be "Well
> it only matters if you're using SSL calls, and you're not, so go to
> hell." ... This from a RedHat systems engineer:
> 
> >It is a warning, not an error.  You may ignore it.
> >It simply means the modules were compiled for a non-SSL-enabled version
> >of Apache.  If the modules do not use any SSL functionality, there will
> >be no problem.
> 
> Whatever, I guess I have take their word for it (or roll my own with
> Open SSL which I really can't spare the time to fight with.) Anyway,
> some simpler early test versions of the module (before adding the DBI
> and HTML::Template stuff) worked, so I THINK mod_perl is OK. There are
> some registry scripts running against the same httpsd and mod_perl to
> support this assertion.

It is actually not that hard to roll OpenSSL into mod_perl+apache.  You
are going to have a worse time trying to get Redhat's SSL foo working. 
Apparently they are using Ralf's EAPI to hook SSL in.  There are very
good technical reasons why EAPI hasn't been shipped with the official
Apache distribution, which I won't bother to explain here.  Suffice it
to say that it is not that well tested in the real world.

Perhaps you should try Ben's ApacheSSL, which has always been my
favorite because 1) it uses a patch to Apache, not an experimental
module interface and 2) Ben isn't an asshole like that other guy.

-jwb

> Nothing is really showing up in the logs (the warning does, nothing
> else), I'm wondering if this rings a bell with anyone.
> 
> Perhaps someone could point me to a clearer explanation of Apache::DBI
> persistent connections etc...
> 
> I'm still a bit mystified as to the difference for scoping and name
> spaces between scripts (modules) that are handlers and scripts that run
> under Apache::Registry. I have read Stas's section on this AND man
> APache::DBI AND perldoc DBI AND Jeff Baker's thing. Unfortunately they
> didn't clear up my confuson. For various reasons (aparently including
> masocisim ) I am trying to write my own handler.
> 
> Thanks,
> John Walker

Re: numerous segv's, bus error

[DeWitt Clinton]

[apologies if people get this twice -- it seemed to bounce the first time]

> We've been getting many segv's and bus errors on apache processes since
> adding modperl.  Env: Apache 1.3.11 (though we had the same thing
> under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00.

If you compare this to my earlier post this week, I believe we are having
the same problem. 

I've tried rolling back to 1.3.9 as well and had the same problem.  I'm
running Linux 2.3.39 and 2.2.15, btw -- it's interesting to note that you
are having this problem on another system.  I've tried every possible
configuration of static/dynamic I can think of, too.  Setting
PerlFreshRestart to "off" didn't seem to do the trick for me either.  I
tried using the latest cvs snapshot of mod_perl with no luck.

I agree -- this is a problem with the cleanup.  In a way I'm glad it's not
just me, although I'm really sorry you are being bit by this too!

Hopefully someone will have an idea.

-DeWitt

OT: mod_proxy & socket error

[Ian Struble]

Hi all,

I have been getting the following error when I try to do some stress 
testing on a machine:

[error] [client 10.1.1.1] (55)No buffer space available: proxy: error
creating socket

Basically the box is just the front end proxy to a backend process that 
is running on another machine.  It is running FreeBSD 3.4-RELEASE.  I 
tweaked kern.ipc.maxsockbuf.  But since I am trying to fetch requests 
from a remote host increasing this setting did not help.  I am guessing 
that I am going to have to tweak some of the net.inet values to increase 
the buffers for the nic but I just can not seem to see the forest through 
the trees right now.  If anyone has already run into this or a similar 
problem in the past I would love to get the answser on a silver platter :^) 

Thanks and sorry for the slightly off topic post.  

Ian

Re: make test

[Ilan Bar-On]

That was a good guess.

In fact I had the following definition in my /etc/hosts

127.0.0.1   localhost.localdomain   local

is seems that the alias localhost is important.

Thanks.
Ilan

- Original Message -
From: Stas Bekman <[EMAIL PROTECTED]>
To: Bruno Connelly <[EMAIL PROTECTED]>
Cc: Ilan Bar-On <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: éåí ùðé, éðåàø 24, 2000 10:46
Subject: Re: make test


> >   Ilan> When I am connected to the net(inetrnet) everything continue
> >   Ilan> to work fine.
> >
> >   Ilan> However, when I am offline,  make test fails.
> >   Ilan> It complains about:
> >
> >   Ilan> still waiting for server to warm upnot ok
> >   Ilan> server failed to start!
> >
> > Perhaps this is because the interface it's trying to bind() to isn't
> > plumbed yet?
>
> [tx... well, well]
>
> Do you have this entry in /etc/hosts?
>
> 127.0.0.1   localhost.localdomain   localhost
>
> Do you have a loopback device [lo] configured? [hint: try 'ifconfig lo']
>
> Having these fixed will solve your problem.
>
> ___
> Stas Bekmanmailto:[EMAIL PROTECTED]  http://www.stason.org/stas
> Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
> perl.apache.orgmodperl.sourcegarden.org   perlmonth.comperl.org
> single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
>
>

Running 2 httpd on one mache question.

[Martin A. Langhoff]

Hi all,

I've read all the documentation on how to run 2 different httpd, one
for lightweight serving and a mod_perl enabled daemon. Also read the
threads about this last weeks.

But there's one thing that I can't imagine. When I run top, how do I
tell memory/cpu consumption from lightweight daemons from the mem/cpu
consumption from mod_perl daemons?

Thanks in advance..


ml

Re: Running 2 httpd on one mache question.

[Joshua Chamas]

"Martin A. Langhoff" wrote:
> 
> Hi all,
> 
> I've read all the documentation on how to run 2 different httpd, one
> for lightweight serving and a mod_perl enabled daemon. Also read the
> threads about this last weeks.
> 
> But there's one thing that I can't imagine. When I run top, how do I
> tell memory/cpu consumption from lightweight daemons from the mem/cpu
> consumption from mod_perl daemons?
> 
> Thanks in advance..
> 

A couple ways, first, the mod_perl httpd will be taking up much
more RAM, but what I really do is rename the lightweight httpd
binary to another name, like phttpd (for proxy-httpd), or some 
such, then its real easy to tell.  You'll have to change the 
apachectl command script with the new binary name of apache.

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

Re: Running 2 httpd on one mache question.

[John Hurst]

"Martin A. Langhoff" wrote:
> 
> But there's one thing that I can't imagine. When I run top, how do I
> tell memory/cpu consumption from lightweight daemons from the mem/cpu
> consumption from mod_perl daemons?

I create a symlink to httpd, and then use that to start the process:

  ln -s httpd httpd_perl
  httpd_perl -d /wherever

My mod_perl processes then show up in top as 'httpd_perl'

-jh

mod_proxy problem

[Eugene Miretskiy]

Hello,

I want to cache the output of mod_perl scripts (they produce
correct content-length, last-modify, and expires headers).

If I put, ProxyPass/ProxyPassReverse directive in server section,
everything works fine.  But if I put these directives inside VirtualHost,
the content is no longer cached.

Any ideas?


-- 
  Eugene Miretskiy <[EMAIL PROTECTED]>
  InVision.com, INC.  (516) 543-1000
  www.invision.net  /  www.longisland.com

Re: loading mod_perl DSO on a per-virtualhost basis?

[Thomas Corte]

Hello,

On Wed, 26 Jan 2000, G.W. Haywood wrote:

> > If not, what is the real benefit of DSO
> 
> It's intended to save memory, by sharing it between processes.

Well, this is exactly what I want :). Currently, I have mod_ssl and
mod_perl linked statically into my httpd binary (under HP/UX 11),
which as a result is about 3MB big. "top" yields a process size
of about 9MB, with about 4,5MB resident for each httpd running.
This size seems to  cause some memory and swapping problems.

So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect
to decrease top's values above significantly?

_

Thomas Corte
<[EMAIL PROTECTED]>

Re: problem with variables sticking.

[Joshua Chamas]

Etienne Pelaprat wrote:
> 
> Hi,
> 
> this is a huge problem.  I have a module written a module with a form
> on it, and for some reason or another if one user fills out the form
> and presses the submit button (doing its stuff), and then another
> different user happens to access that same module to display the same
> form at around the same time the first user presses submit, the form
> loads with the values that the first user put into the fields.  Does
> any one have any idea how this could possibly be happening?  It's only
> happening with mod_perl modules, never happened with my perl
> scripts
> 

Welcome to mod_perl!  Since perl persists, your data may
stay around between requests ... try putting "use strict;"
at the top of your programs & modules, and work through
those issues.  Use 'my $var' when variables should be 
localized... give the modperl guide a good couple reads too!

  http://perl.apache.org/guide/

The problem you are having is documented in the guide.

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

problems with mod_proxy_add_forward / ProxyRemoteAddr

[Peter Bailey]

Hi, I've searched the mailing list archive, but haven't
seen an answer yet, so I'm hoping someone can help.

I'm using the classic setup of having a lightweight Apache
frontend with mod_proxy (and Ask Bjoern Hansen's mod_proxy_add_forward
extension for setting the X-Forwarded-For header). Proxied
requests are passed to the mod_perl Apache backend. For some
of the requests, I need to find the originating host, not the
localhost 127.0.0.1 IP address, so that I can select which
data set the request should be serviced by. (The service
is a search engine service, where all the GUI is written in Perl.)

The setup is all as per the mod_perl guide (other than calling
the package name IpFix instead of My). So I have a line in the
mod_perl httpd.conf with:

PerlPostReadRequestHandler IpFix::ProxyRemoteAddr

I've even got the system working fine on the experimental server.
However, when moving over the installation to the live server yesterday,
I ran into a problem, where the ProxyRemoteAddr code does not appear
to be receiving its argument correctly.

The error message coming from the error_log file is as follows:

Use of uninitialized value at PerlPostReadRequestHandler subroutine
`IpFix::ProxyRemoteAddr' line 1.

Subsequent error messages complain about the access to
$r->connection->remote_ip

Use of uninitialized value at /usr/local/lib/perl/IpFix.pm line 17.

which suggests to me that the $ argument to ProxyRemoteAddr is
failing to be passed.

I've checked that the mod_proxy_add_forward code is compiled
into the front end Apache server (it is). And the url is definitely being
proxied to the backend, because my perl code is reporting a url for
http://localhost:8080/perl/search/internaltest (and this is the code
being executed). The mod_perl back end has been built with
PERL_UTIL_API=1, EVERYTHING=1 settings to make sure Apache:: objects should
all be available. And I use Apache::Registry in startup.pl
and the IpFix package.

Can anyone suggest where it's going wrong?

All help gratefully received - I can't see why it shouldn't
be getting this correct.

Thanks,

Peter

--
Peter Bailey   ph: +61 2 6249 3460
ACSys CRC; Dept of Comp Sci, FEIT, ANU
Canberra ACT 0200 Australia

SIG __WARN__ and (unrelated) mail digest

[John A. Hempe]

How do I get a friggin' daily digest of this barfimonious list instead of
the full barf?

Just for something more on topic, how do I disable specific warnings in
mod_perl?

Bad and weird things seem to happen when I try to handle SIG{__WARN__} even
when I hide it as local.  Is there any other way to pragma out specific
warnings?

--John Hempe

several program w/ mod_perl

[vinecent hong]

Hello,

while I begin to  write some test perl script to test mod_perl after  read
necessary document,still get folloing error.please correct my error(maybe
silly one)

Following is my problem while using mod_perl.
apache 1.3.3 + mysql 2.22 + RH  6.0 + modperl 1.21 + perl 5.005_3
Modperl build w/ everything=1
apache conf:

Alias /perl//usr/local/apache/share/cgi-bin/
PerlFreshRestartOn
PerlRequire /usr/local/apache/share/cgi-bin/include/startup.pl
#PerlSetupEnv OFF
PerlSendHeader OFF
#DBI_TRACE "2=/tmp/dbitrace.log"
PerlModule Apache::DBI


SetHandler  perl-script
PerlHandler Apache::Registry
# PerlSendHeader On
Options +ExecCGI



SetHandler  perl-script
PerlHandler Apache::Status

+

and the startup.pl is below:
use CGI;
use Apache::DBI;
use strict;
Apache::DBI->connect_on_init
("DBI:mysql:uwang::localhost",
"uwang",
"uwang",
{
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 1 # commit executes immediately
}
);
1;

I did read the mod_perl,cgi-to_mod_perl,mod_perl_traps and
perl.apche.org/guide before coding.

now weird problem is:
1. since I use connect_on_init and set dbi trace,I think once the apache
server start,it should automatically create a dbh connection,aka dbh,is it?
but i never see this info in /tmp/dbitrace.log  .why?

2.dbitrace.log did log any connection  made by my mod_perl script.something
like below:
DBI 1.06 dispatch trace level set to 2
-> DBI->Apache::DBI::connect(DBI:mysql:uwang::localhost, uwang, uwang,
HASH(0x830d900))
<- FETCH= 'mysql' ('Name' from cache) at DBI.pm line 64.
-> ping for DBD::mysql::db (Apache::DBI::db=HASH(0x821db30)~0x821db00)
<- ping= 1 at DBI.pm line 112.
^
-> STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'RaiseError' 0)
<- STORE= 1 at DBI.pm line 400.
-> STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'PrintError' 1)
<- STORE= 1 at DBI.pm line 400.
-> STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'AutoCommit' 1)
<- STORE= 1 at DBI.pm line 400.
<- connect= Apache::DBI::db=HASH(0x821db30)
^

Now here is 2 questoin. first is,does the ping=1... line means what the
guide document said "it will ping if a exist dbh still   alive" ?so does the
ping=1 means "Yes,I've find a exist dbh and it's ok"?since these info is
generate by my first connection in my script,does it means it's ping the dbh
create by the apache::DBI connect_on_init?butjust the connect_on_init not
logged? the 2nd is,the connect line, does this means,"ok,I will tell  the
mod_perl script to use a exist dbh HASH(0x821db30)"?  if so,means the script
is REUSE the dbh as we expect.Also,I am  quite sure  because when I reload
the script again and find out that above log info  occur again,yeah,so does
it means the 2nd connection still reuse the same dbh?
I am happy at first but later all changed. TO test if its true,I use ab to
do the test,I run with:
./httpd -X
then
./ab -n 10 -c 10 myscript.pl

during the runtime,I use mysaladmin processlist to see it it REALLY just
create one connection.and :-( NO,NOT at all.tens of mysql connection
there...why? Do I understand above log info  wrongly or config the
httpd.conf file wrong?

Ok,with above configuration,another problem there.my script just do one
thing,"select username from user where id=1".the problem is funny.in the
first time I run the script,the homepage generated like :

test blah blah blah--->just one line

Ok,then I reload it via hit the Refresh button of browser,ok now it looks
like:
test blah blah blah--->just one line
test blah blah blah--->the 2nd  line!!!

so when you  refresh again,just add another SAME line.Seems the sql query
was cached??when I hit the  REFRESH button,its funny that  it not only
execute the sql query in this request,but also execute the one I execute
before.so when you refresh 10 times,you got 10 line.I am blur and I didn't
think I use any sentence could make this problem occur.


Also,I set the StartServer is 15 in  httpd.conf.before I startup apache,it
will start 15 apache child.ok,before start apache,there is just 1 mysqld
there,as soon as I start up apache,it 's 16 now.yes,each apache child
establish a mysql connection,seems the connect_on_init works,but now what I
want?



Thank you all very much,

Vincent

__
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001

Re: Running 2 httpd on one mache question.

[Leslie Mikesell]

According to Martin A. Langhoff:

> But there's one thing that I can't imagine. When I run top, how do I
> tell memory/cpu consumption from lightweight daemons from the mem/cpu
> consumption from mod_perl daemons?

Sorry for the low mod_perl content, but if you are running Linux
and have X available on the network, it is fun to use 'lavaps'
which you can find with a search at www.freshmeat.net.  It shows
processes as though they were in a lava lamp, with the size
corresponding to memory usage, the color and movement related
to activity.  Besides being fun, it gives you a good feeling
for the relationship of the front/back end servers, database
backends, java servlets, and whatever else you might be running.

  Les Mikesell
   [EMAIL PROTECTED]

Re: PLEASE HELP - ERROR Linking Apache with mod_perl

[Stas Bekman]

Asghar, I've answered this question a few days ago - look at the archives!
(hint: perl.apache.org) search for PL_perl_destruct_level

(it'll show up in the next guide's release)

> I hope somebody could respond to this problem.
> 
> 
> I get the following link error when I try to make apache_1.3.9 with 
> mod_perl-1.21. Am I missing a library module?
> 
> Thanks,
> 
> -Asghar
> 
> 
> This is how I built it:
> cd mod_perl-1.21
> perl Makefile.PL PREP_HTTPD=1
> make
> make test
> make install
> 
> cd ../apache_1.3.9
> ./configure --with-layout=RedHat --target=perlhttpd 
> --activate-module=src/modules/perl/libperl.a
> 
> 
> 
> 
> 
> 
> gcc -c  -I./os/unix -I./include   -DLINUX=2 -DTARGET=\"perlhttpd\" -DUSE_HSREGEX 
> -DUSE_EXPAT -I./lib/expat-lite `./apaci` buildmark.c
> gcc  -DLINUX=2 -DTARGET=\"perlhttpd\" -DUSE_HSREGEX -DUSE_EXPAT 
> -I./lib/expat-lite `./apaci`\
>   -o perlhttpd buildmark.o modules.o modules/perl/libperl.a 
> modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a 
> regex/libregex.a lib/expat-lite/libexpat.a  -lm -lcrypt
> modules/perl/libperl.a(mod_perl.o): In function `perl_shutdown':
> mod_perl.o(.text+0xf8): undefined reference to `PL_perl_destruct_level'
> mod_perl.o(.text+0x102): undefined reference to `PL_perl_destruct_level'
> mod_perl.o(.text+0x10c): undefined reference to `PL_perl_destruct_level'
> mod_perl.o(.text+0x13b): undefined reference to `Perl_av_undef'
> 
>  MORE ERROR
> 
> 



___
Stas Bekmanmailto:[EMAIL PROTECTED]  http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org   perlmonth.comperl.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com

Re: Virtual Hosting with Mod_perl?

[Brad Cox]

I think Minerva has what you need. Chantilly Virginia. 
http://www.minerva.net. Haven't tried their virtual hosting though, 
just their colocation for a physical host.

At 10:01 AM -0500 01/26/2000, David Jourard wrote:
>Hi,
>
>I know its a bit off-topic (my apologies) but I thought that for 
>sure someone from the list could recommend a web-hosting company 
>that has a virtual host account with mod_perl and SQL such as mySQL, 
>mSQL and/or Oracle, and possibly with your own apache web server, 
>and of course good tech support and performance.
>
>Thanks in advance
>
>David

Re: problem with variables sticking.

[Stas Bekman]

> this is a huge problem.  I have a module written a module with a form 
> on it, and for some reason or another if one user fills out the form 
> and presses the submit button (doing its stuff), and then another 
> different user happens to access that same module to display the same 
> form at around the same time the first user presses submit, the form 
> loads with the values that the first user put into the fields.  Does 
> any one have any idea how this could possibly be happening?  It's only 
> happening with mod_perl modules, never happened with my perl 
> scripts

Actually we do have the idea, please read:
http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret
http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it

And remember: "mod_perl hates sloppy programmers and punishes them" :) 
(hint: *all* variables should be *initialized*)

___
Stas Bekmanmailto:[EMAIL PROTECTED]  http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org   perlmonth.comperl.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com

Re: Running 2 httpd on one mache question.

[Stas Bekman]

> I've read all the documentation on how to run 2 different httpd, one
> for lightweight serving and a mod_perl enabled daemon. Also read the
> threads about this last weeks.
> 
> But there's one thing that I can't imagine. When I run top, how do I
> tell memory/cpu consumption from lightweight daemons from the mem/cpu
> consumption from mod_perl daemons?

You didn't read *all* the documentation, since it's all there:
http://perl.apache.org/guide/scenario.html#One_Plain_and_One_mod_perl_enabl

(hint: You give the executables different names)

But once you start using mod_perl for real, you will be able to tell the
difference without the above trick, since the difference in size is about
1:5 to 1:15 depening on the number of code you load in...

___
Stas Bekmanmailto:[EMAIL PROTECTED]  http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org   perlmonth.comperl.org
single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com

efficiency questions (templates, regexes, db calls)

[Steven Champeon]

Hi, gang. I'm working on my first serious mod_perl app, and have a few
questions regarding efficiency -- basically looking for traps I may not
have internalized after reading the mod_perl_traps page and so forth.

I'm developing a site that will use MySQL on the backend to store some
info related to goofy timewasting projects (e.g., name, url, contributor,
date last updated, description, etc.) The idea is that there really needs
to be a site where I can list all my goofy timewasting projects, and I
want other people to submit their stuff, too. Sort of a freshmeat for the
random non-commercial stuff that abounds on the 'Net, but which seems to
be neglected in this weblog age, or doesn't get much notice unless it's an
Open Source [tm] project with millions of contributors. :)

Anyway. I have been designing the templates for each class of page on the
site (main project list, individual project detail, admin forms, and so
forth). I want to populate each template with data from the db.  I don't
particularly want to use EmbPerl; I'd rather read the templates at init
time and parse in the db data when the page is to be returned.  Are there
any traps I should be aware of? I only have four or five relatively small
templates, so memory consumption shouldn't be a big deal. From what I 
understand from reading the Guide, these vars will likely be shared,
anyway, right, if I make the vars global and populate them at startup?

I figure I'll put the actual perl modules in lib/perl/, and put the
templates I'm going to use in directories under docroot that correspond
to the handler I've defined, just for sanity's sake. So, 


 SetHandler perl-script
 PerlHandler Apache::Hello


would use templates found in $docroot/hello, and so on. But the actual
templates would be loaded at httpd init time, and kept around, then
I'll perform substitutions on them based on user input or database info.

I know about using /o to compile a regex. The embedded tokens in the
templates won't change, so this will probably work fine, right?

(e.g.:

 

can be replaced by the variable's value on the fly, without hitting
the disk to open the template file:

 my $variable = "something I got from a form or db";
 my @lines = split($GLOBAL_VAR_CONTAINING_TEMPLATE_GUTS);
 while(@lines) {
   s//$variable/o;
   print;
 }

I know to use persistent db connections and pre-load DBI. I know to
tweak Max* to maximize performance. I'm just wondering if there's any
other obvious traps that come to mind. Thanks in advance.

Steve

Re: Results of calling perl_shutdown in mp_dso_unload

[Doug MacEachern]

On Fri, 21 Jan 2000, Daniel Jacobowitz wrote:

> (with appropriate changes to unload DSOs after shutting down perl, of
> course).
> 
> I still get memory leakage - that's not terribly surprising - but it is much
> less.  It's on the order of about 24K/restart and is probably the fault of
> some module - my guts would be DBD::Pg.  I'll play around with that later. 
> It's small enough to show that the idea is workable.
> 
> Restarts are also a bit slower, unsurprisingly - there's a lot more to do.

right, that's one of the reasons restarts are a noop for mod_perl by
default (not including dso-magic)
 
> Then we have the fact that this currently removes PerlRestartHandler
> functionality and goes far beyond PerlFreshRestart.  Those are a big issue -
> those will HAVE to work differently depending on whether or not mod_perl is
> a DSO.  If not, they can continue to work as before, but if it is they will
> never be invoked.
> 
> I'll clean up the patch and fire it off later this weekend, if Doug doesn't
> get a chance to look at it before then.

Doug is slowly crawling back from the death flu :-/
I'm think about releasing 1.22 as it stands in the cvs tree, since it's so
long overdue, and bang out the dso issues from there.  as much as I want
to cure the dso problems, I don't want to introduce new problems the
currently stable static configuration.

Re: PerlFreshRestart and %INC

[Doug MacEachern]

On Thu, 2 Dec 1999, Michael Smith wrote:

> I'm experiencing difficulties when using PerlFreshRestart modules that
> depend on %INC.  In my particular case I'm trying to use persistent
> connections in DBI through Apache-DBI, and Apache/DBI is not in %INC
> when PerlFreshRestart causes DBI to be loaded a second time.

there's a change in the cvs tree that might help:
PerlFreshRestart semantics changed to preserve order of PerlModule's
and not to reload modules while actually iterating over %INC

so if you configure:
PerlModule Apache::DBI DBI

they should both be reloaded in that order.

RE: mod_perl 1.21 -> CGI.pm 2.56 error in phase other than conten t

[Doug MacEachern]

from chapter 9 of wrapmod:

There are a number of standard variables that Apache adds to the
environment prior to invoking the content handler. These include
DOCUMENT_ROOT and SERVER_SOFTWARE.  By default, the complete C<%ENV>
hash is not set up until the content response phase.  Only variables
set by B, B and by I itself will be
visible.  Should you need the complete set of variables to be
available sooner, your handler code can do so with the
I method.  Example:

 my $r = shift;
 my $env = $r->subprocess_env;
 %ENV = %$env;

On Wed, 22 Dec 1999 [EMAIL PROTECTED] wrote:

> >  
> >  
> >  >  PerlPostReadRequestHandler 'sub { Apache->request(shift) }'
> >  
> >  doug,
> >  thanks for the response.  I had tried the bandaid with no luck.
> >  Probably should have said that in the post :-) 
> 
> Ok having realised that the Handler wasn't getting called as I already had
> another PerlPostReadRequestHandler being called the issue is getting
> clearer
> 
> I am trying to call CGI within a PerlAuthenHandler
> 
> I can new correctly create the CGI object, i.e. it no longer falls over on
> registering it's callbacks.  However it does not get any of the data. Now I
> presume this is because the CGI environment is not yet set up.  In the
> server log it appears to be working offline..  So I tried adding to the
> environment before calling CGI->new setting REQUEST_METHOD CONTENT_LENGTH
> and CONTENT_TYPE.  This creates the object correctly (but without any
> parameters) on a POST request.  It would appear that CGI is not getting
> anything from STDIN.  At the moment I can work around this by calling
> cgi->param for each bit of $r->content, I was just wondering if there is a
> better way fro all of this ?
> 
> SAM
> 

Re: PerlRun and Exporter() vars

[Doug MacEachern]

On Mon, 27 Dec 1999, John M Vinopal wrote:

> More about the undef of package variables.  Sure enough, the variables are
> nuked in PerlRun::flush_namespace().  This can be inhibited by removing
> them from the script's namespace before termination:
> 
> my $name = __PACKAGE__ . '::';
> delete($name->{'VARIABLE NAME HERE'});
> 
> I notice that the 1.17 bug about undefing subroutines was fixed by adding
> some checking code PerlRun::undef_cv_if_owner(), should this same sort of
> thing be done for variables as well?

yes, sounds like that's the case.  thanks for the insights.  >>ToDo

Re: efficiency questions (templates, regexes, db calls)

[Cliff Rayman]

did you check out?
http://search.cpan.org/search?dist=HTML-Template

this might do most of what you need, and handle some things
you haven't thought of yet.

cliff rayman
genwax.com

Steven Champeon wrote:

> Hi, gang. I'm working on my first serious mod_perl app, and have a few
> questions regarding efficiency -- basically looking for traps I may not
> have internalized after reading the mod_perl_traps page and so forth.
>
> I'm developing a site that will use MySQL on the backend to store some
> info related to goofy timewasting projects (e.g., name, url, contributor,
> date last updated, description, etc.) The idea is that there really needs
> to be a site where I can list all my goofy timewasting projects, and I
> want other people to submit their stuff, too. Sort of a freshmeat for the
> random non-commercial stuff that abounds on the 'Net, but which seems to
> be neglected in this weblog age, or doesn't get much notice unless it's an
> Open Source [tm] project with millions of contributors. :)
>
> Anyway. I have been designing the templates for each class of page on the
> site (main project list, individual project detail, admin forms, and so
> forth). I want to populate each template with data from the db.  I don't
> particularly want to use EmbPerl; I'd rather read the templates at init
> time and parse in the db data when the page is to be returned.  Are there
> any traps I should be aware of? I only have four or five relatively small
> templates, so memory consumption shouldn't be a big deal. From what I
> understand from reading the Guide, these vars will likely be shared,
> anyway, right, if I make the vars global and populate them at startup?
>
> I figure I'll put the actual perl modules in lib/perl/, and put the
> templates I'm going to use in directories under docroot that correspond
> to the handler I've defined, just for sanity's sake. So,
>
> 
>  SetHandler perl-script
>  PerlHandler Apache::Hello
> 
>
> would use templates found in $docroot/hello, and so on. But the actual
> templates would be loaded at httpd init time, and kept around, then
> I'll perform substitutions on them based on user input or database info.
>
> I know about using /o to compile a regex. The embedded tokens in the
> templates won't change, so this will probably work fine, right?
>
> (e.g.:
>
>  
>
> can be replaced by the variable's value on the fly, without hitting
> the disk to open the template file:
>
>  my $variable = "something I got from a form or db";
>  my @lines = split($GLOBAL_VAR_CONTAINING_TEMPLATE_GUTS);
>  while(@lines) {
>s//$variable/o;
>print;
>  }
>
> I know to use persistent db connections and pre-load DBI. I know to
> tweak Max* to maximize performance. I'm just wondering if there's any
> other obvious traps that come to mind. Thanks in advance.
>
> Steve

Re: Results of calling perl_shutdown in mp_dso_unload

[Daniel Jacobowitz]

On Wed, Jan 26, 2000 at 08:13:41PM -0800, Doug MacEachern wrote:
> right, that's one of the reasons restarts are a noop for mod_perl by
> default (not including dso-magic)

Makes sense.

Here's a question - an apache patch should be able to mark the module
as not-to-unload (although since it should be
not-to-unload-unless-removed-from-config it would be a bit more
complicated than that - still not impossible).  But is that worthwhile
or should we just adjust to being unloaded if built as DSO?

> > Then we have the fact that this currently removes PerlRestartHandler
> > functionality and goes far beyond PerlFreshRestart.  Those are a big issue -
> > those will HAVE to work differently depending on whether or not mod_perl is
> > a DSO.  If not, they can continue to work as before, but if it is they will
> > never be invoked.
> > 
> > I'll clean up the patch and fire it off later this weekend, if Doug doesn't
> > get a chance to look at it before then.
> 
> Doug is slowly crawling back from the death flu :-/
> I'm think about releasing 1.22 as it stands in the cvs tree, since it's so
> long overdue, and bang out the dso issues from there.  as much as I want
> to cure the dso problems, I don't want to introduce new problems the
> currently stable static configuration.

Understood - good idea.

Which reminds me - the CVS instructions linked from perl.apache.org no
longer work.  Is there a public CVS archive still?  Where did it move?

Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/

Re: mod_perl and Content-Negotiation

[Doug MacEachern]

On Tue, 28 Dec 1999 [EMAIL PROTECTED] wrote:

> I'm using Apache/1.3.9, mod_perl/1.21, mod_ssl/2.4.9, OpenSSL/0.9.4
> with Content Negotiation enabled (mod_negotiation).
> 
> My idea was to use this feature for mod_perl-scripts,also.
> So I created to scripts for testing:
> - test.pl.en
> - test.pl.de
> 
> The first time I accessed /perl/test.pl I got the output of test.pl.de
> (because my favorite Language is "de" ...)
> I changed the Language to "en" in my Browser and reloaded the
> script. But the output was still from test.pl.de.
> 
> It's clear, because the scripts are cached by URI and it was "/perl/test.pl"
> for both tries.
> 
> I have changed following lines in site/5.00503/lib/ApacheRegistry.pm to 
> cache the scripts by absolute filename:
> 
> 62: # del by [EMAIL PROTECTED]
> 63: #my $script_name = $r->path_info ?
> 64: #substr($uri, 0, length($uri)-length($r->path_info)) :
> 65: # $uri;
> 66: # ins by [EMAIL PROTECTED]
> 67: my $script_name = $filename;
> 
> And it seems to work.
> 
> And here are the questions:
> Is it *nice* what I have made ?
> Do You see any troubles (or impacts) with that change ?
> Why do You take the URI ?

Apache::RegistryNG uses the filename instead of uri.  uri was chosen
because there used to be a limit to the length of Perl package names.  and
regardless, shorter package name based on the uri uses less memory and
provides a faster lookup than the filename.

Re: Status in httpd access log

[Doug MacEachern]

have a look at Apache::RedirectLogFix

On Thu, 6 Jan 2000, Mark Nudelman wrote:

> I'm writing my first module using modperl, so I'm probably doing
> something really wrong, but I haven't been able to figure this out.  I
> want my script to return an HTTP error code to the client, and I want
> that error code to be logged to the httpd access log.  If I use this
> script:
>   my $r = Apache->request;
>   $r->status(304);
> everything works as expected: the client receives a "304 Not Modified"
> status line, and the log shows a "304" status.
> 
> But if I do this:
>   $r->status(304);
>   $r->err_header_out("X-Test-Header" => "abc");
>   $r->send_http_header();
> then the client still receives the 304 status as expected, as well as
> the extra header, but the log shows a status of 200, not 304.  In fact,
> the err_header_out doesn't matter; if I just call send_http_header, the
> log shows 200.  How can I make the log show the correct status?
> 
> Another problem is that in some cases, such as if I return a "400 Bad
> Request" status, I'm getting a "Connection: close" header as well.  Is
> there any way I can control this?  I don't want to send a Connection:
> close header, even if I return an error status.
> 
> Thanks for any help,
> --Mark
> 

Re: Perl modules in apache configuration

[Doug MacEachern]

if you compile modperl with PERL_TRACE=1 and setenv MOD_PERL_TRACE s
then you should see some useful diagnostics when mod_perl is processing
 sections.

On Sun, 9 Jan 2000 [EMAIL PROTECTED] wrote:

> Hello!
> 
> I'm trying to configure httpd.conf using Perl sections (mod_macro is
> not enough for me), but the result is weird. 
> 
> The most weird thing is that Perl sections randomly doesn't execute! I
> have no experience (yet) with Perl configuration modules, so I don't
> understand where to start tracking.
> 
> mod_perl developers' guide didn't help, as perldoc mod_perl :-(
> 
> -- 
> Alexander B. Povolotsky[ICQ 18277558]
> [2:5020/145][[EMAIL PROTECTED]]
> 

Re: Memory leak/server crashes

[Doug MacEachern]

there are hints in the SUPPORT doc on how to debug such problems.  there
was also several "Hanging process" threads in the past weeks with more
tips, search in the archives for keywords gdb, .gdbinit, curinfo
if you can get more insight from those tips, we can help more.

On Sun, 9 Jan 2000, James Furness wrote:

> I'm looking for some help getting apache to run reliably. Apache 1.3.9 with
> mod_perl 1.21 and Perl 5.005_03 is running on a dual P500 with 1 Gb of RAM
> running Redhat 6.1. We run about 5 sites off the box, most of which are
> fairly high traffic, and use a lot of CGI and
> MySQL 3.22.25 is used with Apache::DBI.
> 
> The major problem seems to be a memory leak of some sort, identical to that
> described in the "memory leak in mod_perl" thread on this list from October
> 1997 and the "httpd, mod_perl and memory consumption (long)" thread from
> July 1997.
> 
> The server runs normally for several hours, then suddenly a httpd process
> starts growing exponentially, the swapfile usage grows massively and the
> server starts to become sluggish (I assume due to disk thrashing caused by
> the heavy swap usage). Usually when this started to happen I would log in
> and use apachectl stop to shutdown the server, then type 'killall httpd'
> several times till the processes finally died off, and then use apachectl
> start to restart apache. If I was not around or did not catch this, the
> server would eventually become unresponsive and lock up, requiring a manual
> reboot by the datacentre staff. Messages such as "Out of memory" and
> "Callback called exit" would appear in the error log as the server spiralled
> down and MySQL would start to have trouble running.
> 
> To combat this, I created a script to monitor load and swapfile usage, and
> restart apache as described above if load was above 7 and swapfile usage
> above 150Mb. This script has kept the server online and we now have an
> uptime of something like 22 days (previously no more than 1 day), but the
> script is getting triggered several times a day and no more "Out of memory"
> messages are appearing, but the situation is not ideal.
> 
> I have tried adding:
> 
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> Carp::cluck "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> }
> 
> 
> As recommended by the developers guide, which flooded the error log with the
> text below being printed roughly once a second in the error log:
> 
> -
> Apache=SCALAR(0x830937c) can't $UNIVERSAL::AUTOLOAD!
> Apache=SCALAR(0x8309364) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
> IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
> --
> 
> I've pretty much exhausted any ways I can think of to trace this problem,
> such as i've tried to eliminate memory leaks in code by removing some
> scripts from mod_perl and running them under mod_cgi and i've tried tweaking
> MaxRequestsPerChild both without any success.
> 
> One thing that was mentioned in a previous thread was that using 'exit'
> could confuse perl, and exit() is used fairly heavily in the scripts since
> most are converted to mod_perl from standard CGIs, but i'd prefer not to
> have to remove these since the structure of the scripts is reliant on some
> form of exit statement. Is there some alternative to exit()?
> 
> I've also had a look at some of the patches to Apache.pm and Apache.xs
> suggested in the previous threads, and these seem to have been incorporated
> into mod_perl 1.21.
> 
> Are there any other solutions I could try to this problem? Does anyone know
> what might be causing this?
> 
> The second problem I have is when loading pages, usually CGI, but I think
> this has happened on some static pages, what IE5 describes as "Server not
> found or DNS error" is experienced. Originally I thought this was the server
> hitting MaxClients (150) since it usually occurs at the same time as massive
> surges of hits, and /server-status usually shows 150 httpd processes have
> been spawned, however I increased MaxClients to 200 recently and the error
> has continued to happen, even though /server-status doesn't show any more
> than about 170 processes spawned. I have not ruled out DNS server troubles
> or backbone problems (We've had a few routing troubles recently that slowed
> things down, but not actually cut off traffic or anything like that), but I
> am at a loss as to what else could be causing this so I thought i'd ask
> whilst i'm on the subject of server problems :)
> 
> Thanks in advance,
> --
> James Furness <[EMAIL PROTECTED]>
> ICQ #:  4663650
> 

Re: Help

[Doug MacEachern]

sounds like your script is running under mod_cgi, not mod_perl

On Tue, 11 Jan 2000, Akio wrote:

> I´m programming in mod_perl and I'm trying to use libapreq-0.31 but
> when I call method new, I get the msg "Can't locate object method "new"
> via package
>  "Apache::Request"".
> 
>  The package (module) that use it has a statement "use Apache::Request (
> )"
>  and the next statement is :
> 
> my $r= Apache::Request->new(shift);
> 
>  I have it installed in a Sun Solaris server (not i86) and I´m using
> Perl
>  5.005. I have downloaded it from CPAN site.
> 
> Anyone can help me?
> 

Re: problems with module at root of web site

[Doug MacEachern]

On Wed, 12 Jan 2000, Sean Chittenden wrote:

>   Mind if I ask a nit-pick of a performance question?  Currently
> speed and performance are of upmost importance (I'm currently involved in
> a mod_perl vs JServ development race).  That being said, isn't pushing a
> handler onto the request stack slower than predefining a handler that the
> request falls through to?  I could be wrong and haven't tested things
> otherwise, but, it would seem like pushing a custom handler (granted it's
> already compiled into byte-code) onto the stack at the time of the request
> would take slightly longer.  I suppose I'd be who of me to test this
> assertion, but if you have any idea as to wether or not this case ahead of
> time, I'd be greatly interested in hearing about your past experience.

I don't think it would be a measurable difference.  the only overhead
using push_handlers vs. .conf is:
-one Perl method call
-growing the Perl*Handler array by 1, if it's not big enough already

RE: mod_perl bug (mod_perl 1.21; Apache 1.3.9).

[Doug MacEachern]

On Wed, 19 Jan 2000, John Hughes wrote:

> > what happens if you preload Apache::Registry in httpd.conf:
> >
> > PerlModule Apache::Registry
> 
> Didn't try that.  But code examination seems to imply that it would have
> no effect.
> 
> 1. Apache::Registry gets run, so:
> 
>   unless (defined $Apache::Registry::NameWithVirtualHost) {
>   $Apache::Registry::NameWithVirtualHost = 1;
>   }
> 
>Now NameWithVirtualHost is 1.
> 
> 2. a non-virtualhost request is received so perl_handler in mod_perl.c does:
> 
> if((nwvh = ApachePerlRun_name_with_virtualhost())) {
> if(!r->server->is_virtual) {
> SAVESPTR(nwvh);
> sv_setiv(nwvh, 0);
> }
> }
> 
>now NameWithVirtualHost is 0.
> 
>and it stays zero forever.
> 
> On reflection my fix is over the top - it has the effect of overriding
> the value of NameWithVirtualHost set by the user.
> 
> I don't think perl_handler should be changing NameWithVirtualHost *AT ALL*,
> that should be left up to the user, with a default in Registry.pm.

it used to be that way, but moved to perl_handler because it's a quicker
check in C, and multiple modules (besides Apache::Registry) need this
logic.

> I attach patches to do that.  They work for me.

thanks.  I'll revisit this soon.
 
> One last query, what about ApachePerlRun_namespace in PerlRunXS.xs, that
> seems to think that the mere existence of the variable NameWithVirtualHost
> implies that names should be modified with the virtualhost.  It doesn't
> check the *VALUE* of the variable:

that's okay, I don't think anybody is using PerlRunXS, I'd be surprised if
it still works at all.  if there's to be a xs/c version ala PerlRunXS,
it's put off until modperl-2.0

Re: Suggested improvements to RegistryLoader.pm - stuff for virtualhosts

[Doug MacEachern]

On Wed, 19 Jan 2000, John Hughes wrote:

> It would be nice if RegistryLoader.pm let me load a script for
> a virtual host in such a way that I didn't have to worry about
> how they were represented.
> 
> Something like:
> 
>   my $r = Apache::RegistryLoader->new;
> 
>   $r->handler($uri, $filename, $virthost);

looks good to me, thanks John!

Re: Problems w/ CGI under mod_perl

[Doug MacEachern]

> perhaps you should call 
> 
> Apache->request->new($r)->register_cleanup(\&CGI::_reset_globals);

there is no Apache::new method

the problem here (which has come up many times in the past), is that
CGI.pm uses the Apache->request method to get a reference to the global
$r.  this normally isn't set until the response phase, unless you do it
yourself, which can be done with a line of config like so:
 
PerlPostReadRequestHandler 'sub { Apache->request(shift) }'

Re: horrible memory consumption

[Doug MacEachern]

have a look at the Apache::Status in the cvs tree, there are hooks into
B::TerseSize which is used to measure Perl memory usage.

On Wed, 19 Jan 2000, Jason Terry wrote:

> Is there a way I can tell where my memory usage is going in an Apache child?
> 
> I have a server that starts with acceptable numbers, but after a while it
> turns into this
> 
> Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 PHP/3.0.12 mod_ssl/2.4.4
> OpenSSL/0.9.4
> Redhat Linux: 2.2.13
> 
> PID   USER PRI  NI   SIZE   RSS SHARE LC STAT %CPU %MEM   TIME  COMMAND
> 9666 nobody-1-1   38900  37M  67681S <   0.07.5
> 6:57/usr/local/apache/bin/httpd
> 9665 nobody-1-1   35728  34M  62401S <   0.06.9
> 5:57/usr/local/apache/bin/httpd
> 9663 nobody-1-1   35312  34M  64121S <   0.06.8
> 6:11/usr/local/apache/bin/httpd
> 
> Now I examined these children using /server-status and they had all recieved
> more than 7000 accesses for each child.
> 
> Is there a way I can find out where all this RAM is being used.  Or does
> anyone have any suggestions (besides limiting the MaxRequestsPerChild)
> 

Re: send_fd and timeout problem

[Doug MacEachern]

On Thu, 20 Jan 2000, Martin Lichtin wrote:

> Doug MacEachern wrote:
> > mod_perl doesn't set it's own alarm when $r->send_fd is called.  did you
> > call $r->print or print before hand?
> 
> Hmm, no, I do something like this:
> 
> $r->content_type('application/octet-stream');
> my($size) = -s $fh;
> $r->header_out('Content-Length', $size);
> $r->send_http_header;
> $r->send_fd($fh, $size);
> close($fh);

you must be seeing logs from another process, none of those calls set an
'Apache->print' timeout.

Re: Performance ?'s regarding Apache::Request

[Doug MacEachern]

On Thu, 20 Jan 2000, Clifford Lang wrote:

> mod_perl 1.21
> Apache 1.3.9
> Solaris 2.5.1, Linux 6.0
> 
> Is this a good or bad idea?
> 
> I want to create an inheritable module based on Apache::Request mainly for
> uploading files, then create individual PerlHandler modules for individual
> page content.
> 
> If I do this, will the uploaded files end up increase the memory consumption
> of the module, or is all memory freed after the fileupload process?

Apache::Request reads the uploaded file in 4K chunks and saves it to a
tmpfile, just as CGI.pm does.  you shouldn't see the process grow to the
size of the file unless you've hit a bug we don't know about.

Re: Can't exec programs ?

[Doug MacEachern]

On Thu, 20 Jan 2000, Pierre-Yves BONNETAIN wrote:

> 
> [EMAIL PROTECTED] said:
> > you'll get a better idea of the problem running strace (or truss) 
> > against the server.  in any case, you should avoid any code that's 
> > forking a process, since it's throwing performance out the window. 
>Is there a 'nice way' (meaning, a patch or manual change I can do to those
> modules) to prevent forking or, rather, replace it by stg else that gets me the
> same thing ? I can spend (a lot of) time looking for system() and
> backticks in the modules I use, but if I need the functionnality how can I 
> 'correct' the code of those modules ?

I don't know of a tool to help with this, you just need to keep an eye on
things with strace or truss and weed out the forking code.

Re: problem

[Doug MacEachern]

On Thu, 20 Jan 2000, Etienne Pelaprat wrote:

> Hi All,
> 
> I've hit a problem that I can't seem to rectify.  I compile 
> mod_perl with EVERYTHING=1, but in one of my modules, I get the error:
> 
> [Wed Jan 19 20:30:05 2000] null: Rebuild with -DPERL_STACKED_HANDLERS 
> to $r->push_handlers at /usr/local/apache/lib/perl/Apache/BOSCIndex.pm 
> line 37.

make sure the rebuilt httpd is the one you're using now.  that's bitten
plenty of us in the past.  EVERYTHING=1 does enable stacked handlers.
if you rebuild again, be sure to start with freshly unpacked source trees
of both mod_perl and Apache.

Re: problem

[Doug MacEachern]

On Thu, 20 Jan 2000, Cliff Rayman wrote:

> unfortunately PERL_STACKED_HANDLERS used to be
> experimental and therefore EVERYTHING includes just
> about EVERYTHING except PERL_STACKED_HANDLERS.
> 
> i think you need to add PERL_STACKED_HANDLERS=1 to
> your long list of Makefile.PL parameters.
> 
> this has been discussed in the mail archives so you can search
> there and you'll find the original message from Doug.

no, PERL_STACKED_HANDLERS is including with EVERYTHING=1

Re: CGI.pm and QUERY_STRING fixup

[Doug MacEachern]

On Mon, 24 Jan 2000, Bill Moseley wrote:
... 
> Under mod_cgi I can clean up $ENV{QUERY_STRING} at the start of a program
> by removing leading '&' and double '&', but that doesn't work, obviously,
> under mod_perl.
> 
> Could someone suggest a way to clean up the query string from within an
> Apache::Registry script?  Is it possible to just write a cleaned up query
> string to args() at the start of my Registry script, or is that too late in
> the request?

PerlFixupHandler would be the best place to fixup $r->args

Re: CGI.pm and QUERY_STRING fixup

[Doug MacEachern]

On Tue, 25 Jan 2000, Bill Moseley wrote:

> Ok, this seems to work, but perldoc Apache doesn't say anything about
> setting it.  Is this at risk of not working in the future?

you can set $r->args, that won't be going away in the future.

Re: Apache::AuthCookie takeover?

[Doug MacEachern]

On Tue, 25 Jan 2000, Ken Williams wrote:
> 
> Can someone set the maintainer of Apache::AuthCookie to be me?

patch below :)
thanks Ken!!

diff -u -u -r1.63 apache-modlist.html
--- apache-modlist.html 1999/11/24 02:40:01 1.63
+++ apache-modlist.html 2000/01/27 05:19:27
@@ -114,7 +114,7 @@
 * PerlAuthenHandler's
 AuthAnybdpfAuthenticate with any username/password
MPB
 AuthenCachebmpfCache authentication credentialsJBODNAR
-AuthCookie bdpOAuthen + Authz via cookies  EBARTLEY
+AuthCookie bdpOAuthen + Authz via cookies  KWILLIAM
 AuthenDBI  bmpOAuthenticate via Perl's DBI MERGL
 AuthExpire i   Expire Basic auth credentials   DOUGM
 AuthenGSS  cdpfGeneric Security Service (RFC 2078) DOUGM

Re: self url

[Doug MacEachern]

On Wed, 26 Jan 2000, Vladimir Ivaschenko wrote:

> 
> Hello,
> 
> Is there a way to get the URL of the current document in Embperl?
> Sort of like $q->self_url in CGI.pm.

from chapter 9 of wrapmod:

If the URI argument is omitted, the I method will construct a
fully qualified URI from B<$r> object, including the scheme, hostname,
port, path and query string.  Example:

 my $self_uri = Apache::URI->parse($r);

Re: numerous segv's, bus errors

[Doug MacEachern]

On Wed, 26 Jan 2000, Steven Parkes wrote:

> We've been getting many segv's and bus errors on apache processes since
> adding modperl.  Env: Apache 1.3.11 (though we had the same thing
> under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00.
> 
> At first most of the failures were coming within visit() during what looks
> to be clean up of children.  PerlFreshRestart is Off.  I added
> PerlSetEnv PERL_DESTRUCT_LEVEL -1
> and that seemed to get rid of many of those though this seems like a less
> than optimal solution and I'd like to better understand what the real
> issue is here.
> 
> Moreover, we still see a number of failures.  Many seem to occur in __errno.
> 
> (gdb) bt
> #0  0xc01ecb88 in kill () from /usr/lib/libc.2
> #1  0x769c8 in sig_coredump () from /usr/local/alpha/apache/bin/httpd
> #2  
> #3  0xc0179214 in __errno () from /usr/lib/libc.2
> #4  0xc01751bc in free () from /usr/lib/libc.2
> #5  0x10013c in Perl_safefree () from /usr/local/alpha/apache/bin/httpd
> #6  0x112248 in Perl_sv_clear () from /usr/local/alpha/apache/bin/httpd
> #7  0x112478 in Perl_sv_free () from /usr/local/alpha/apache/bin/httpd

a buggy xs modules or c library that overwrites memory can trigger these
problems, seemingly random core dumps in free() or malloc().  do you have
a tool such as purify or insure?  they can often identify the problem
right away.  otherwise, we need to know more about your setup to help,
what modules you're using, etc.

Re: Results of calling perl_shutdown in mp_dso_unload

[Doug MacEachern]

On Wed, 26 Jan 2000, Daniel Jacobowitz wrote:
 
> Here's a question - an apache patch should be able to mark the module
> as not-to-unload (although since it should be
> not-to-unload-unless-removed-from-config it would be a bit more
> complicated than that - still not impossible).  But is that worthwhile
> or should we just adjust to being unloaded if built as DSO?

I think both options would be nice to have.

> Which reminds me - the CVS instructions linked from perl.apache.org no
> longer work.  Is there a public CVS archive still?  Where did it move?

things have changed recently, here's a snippet from the latest
mod_perl_cvs.pod:

=item anoncvs

To checkout a fresh copy from anoncvs use

cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login

with the password "anoncvs". 

cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl


For a basic introduction to anoncvs see http://dev.apache.org/anoncvs.txt 

setting perl handler based on MIME type?

[Jim Winstead]

Is there a way to set a PerlHandler for a specific MIME type?
Something like "PerlTypeHandler text/html HTML::Template"?
(Yes, I know I can use a  section. Not quite as slick,
and that mucks up $r->location.)

Jim

Re: Results of calling perl_shutdown in mp_dso_unload

[Jim Winstead]

On Jan 26, Doug MacEachern wrote:
> =item anoncvs
> 
> To checkout a fresh copy from anoncvs use
> 
> cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login
> 
> with the password "anoncvs". 
> 
> cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl

Both of those should have another colon before the pserver. Like:

cvs -d ":pserver:[EMAIL PROTECTED]:/home/cvspublic" login

Jim

Re: using socket on NT's mod-perl

[Joshua Chamas]

Huan He wrote:
> 
> Hello All,
> 
> Does anyone ever write a TCP socket program in mod-perl module on NT ?
> In my program, I use socket in phase PerlAccessHandler to connect
> to a remote socket server, the socket in mod-perl can be opened and
> connected, but when I try to write message to the remote server, the
> server socket always receives null.
> 
> But if I use the same section code of mod-perl in a normal standalone
> perl program, it works fine. Does anyone know why ?
> 

I had this problem too when I had more than 1 ThreadsPerChild,
set this to 1 and you should be fine.

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051