Re: using mod_perl with SSI-run perl scripts

[Perrin Harkins]

On Thu, 17 Aug 2000, Mike Hodson wrote:
> I need to know if mod_perl can execute the perl scripts called by the
> exec cgi SSI command, and if so, instructions on how to make this work
> properly.

Take a look at the mod_perl docs:
http://perl.apache.org/src/mod_perl.html#mod_perl_and_mod_include_integra

- Perrin

using mod_perl with SSI-run perl scripts

[Mike Hodson]

Hello there.
I am currently looking for a way to reduce the server load on a very popular
website.  I must admit, I am not a whiz with perl, nor was I the designer of
our current system.  The web content designer (I myself am a server
administrator) is using a set of small perl scripts run thru the SSI  method to change advertizing banners on different
pages.  I personally want to convert them into some sort of embperl or PHP
code embedded into the pages, however the current number of pages that require
these scripts number in the thousands, and I can't justify changing everything
over if there is another option.

I need to know if mod_perl can execute the perl scripts called by the exec cgi
SSI command, and if so, instructions on how to make this work properly.
Right now our server (p3-550mhz, 768 megs ram, freebsd 4.0) load average is
steady around 5, and spikes to over 20 when people request the SSI enabled
pages. 

Thanks in advance for any help on this subject.

Regards,
Mike Hodson

file download with mod_perl

[pritesht]

I am using following script in perl to download a file from the server to the local 
machine. The great thing about this code is, it populates a file save as dialog. The 
dialog is populated becuase of "Content-type:application/unknown\n 
Content-disposition:attachment;filename=$filetobedownloaded\n\n".
 
 
my ($in) = new CGI;
my ($filetobedownloaded)  = $in->param('filetobedownloaded');
my ($working_dir) = $in->param('wd');
 
print "Content-type:application/unknown\n 
Content-disposition:attachment;filename=$filetobedownloaded\n\n"
my $directory = "$config{'root_dir'}/$working_dir";
 
open (OUTFILE, "$directory/$filetobedownloaded");
binmode OUTFILE;
binmode STDOUT;
 
while () { 
 $in->print($_); 
} 
close (OUTFILE); 

 
However, the same code is not working under mod_perl. The file content is the same as 
original file, but filename is populated as download.cgi instead of actual file name. 
I think mod_perl is putting its own headers, while sending the data.
 
Any help will be greatly appreciated.

Thanks,
Pritesh.
pritesht
e-mail: [EMAIL PROTECTED]






Feed  Your Greed !!!
Get your 10MB Free space only at http://www.forindia.com NOW!

[announce] Apache::DumpHeaders 0.90

[Ask Bjoern Hansen]

The uploaded file

Apache-DumpHeaders-0.90.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/A/AB/ABH/Apache-DumpHeaders-0.90.tar.gz
  size: 2786 bytes
   md5: 6631c3612d14162c87d26a45a29a2283


I just made a minor change and realized that I don't think I
announced this module before. It's very very very tiny but also very
very very useful. At ValueClick we have our application marking
certain transactions (usually those involving "bad data" of some
kind) as "dumpable" and then this module is configured to dump N% of
the transactions that gets marked as dumpable. Then when we want to
work with it we just take a look at the logfile from this module and
we have all the data we need to track what browsers does what weird
things.



Apache::DumpHeaders - Watch HTTP transaction via headers

SYNOPSIS

  #httpd.conf or some such
  PerlLogHandler Apache::DumpHeaders
  PerlSetVar DumpHeaders_File -
  PerlSetVar DumpHeaders_IP "1.2.3.4 1.2.3.5"
  #PerlSetVar DumpHeaders_Conditional 
  #PerlSetVar DumpHeaders_Percent


DESCRIPTION

  This module is used to watch an HTTP transaction, looking at
  client and servers headers.

  With Apache::ProxyPassThru configured, you are able to watch your
  browser talk to any server besides the one with this module living
  inside.





 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Apache 1.3.12/mod_perl 1.23/Activestate Perl 5.6.0 and db persistance

[Eric Smith]

Looking for suggestion as to where we might find the problem in
getting a sample script implementing db persistance working with the
above config on a windows box.

Tries to follow the docs by the following:

 -- add to httpd.conf: 
 PerlModule Apache::DBI

and:

/mod_perl/persistantdbi.pl
==

use DBI (); 
use Apache::DBI;
use strict;

use vars qw($dbh);
use CGI;
my $cgi=new CGI;
use CGI::Carp 'fatalsToBrowser';

print $cgi->header;
print $cgi->start_html("Persistant Test");

use Win32::OLE::Variant;
use Win32::OLE;
use Win32::OLE::Const;
use DBD::ADO;
my $database = "db";
my $user = "port";
my $password = "ahem";
my $ADO_SQL_data_source =
"Provider=SQLOLEDB;Database=$database;Uid=$user;Pwd=$password;";

 $dbh ||= DBI->connect("dbi:ADO:$ADO_SQL_data_source"  )|| print "Error 111";

my $sth = $dbh->prepare('select description from grade');
$sth->execute() || print "error 555";
my @row;
while(@row=$sth->fetchrow) { print @row; }
print $cgi->end_html;

Now this works perfectly (like it prints the result of the sql) on the
first web access.  However when you reload or access again from
another machine or whatever, this in the browser:

HTTP/1.1 200 OK Date: Thu, 17 Aug 2000 22:31:40 GMT Server:
Apache/1.3.12 (Win32)   
   mod_perl/1.23 Connection: close Transfer-Encoding: chunked
Content-Type: text/html; 
   charset=iso-8859-1

and this is the error_log:

[Fri Aug 18 00:31:40 2000] nul: Win32::OLE(0.12): GetOleObject() Not a Win32::OLE 
object at C:/Perl/site/5.6.0/lib/Win32/OLE/Lite.pm line 148.
[Fri Aug 18 00:31:40 2000] nul: Win32::OLE(0.12): GetOleObject() Not a Win32::OLE 
object at C:/Perl/site/5.6.0/lib/Win32/OLE/Lite.pm line 148.
[Fri Aug 18 00:31:40 2000] [error] Can't call method "Clear" on an undefined value at 
C:/Perl/site/5.6.0/lib/DBD/ADO.pm line 47.

thanx
-- 
Eric Smith
Fruitcom.com
Landline: 00 27 21 426 5311
Mobile: 00 27 82 373 1224

Re: Apache Variables

[___cliff rayman___]

2 main things to read for mod_perl apache:
the guide:
http://perl.apache.org/guide/

the book:
http://www.oreilly.com/catalog/wrapmod/


--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
good luck,

[EMAIL PROTECTED] wrote:

> Let me start with "I'm new".
>
> If this is the wrong forum, let me know now and please direct me to the right
> place.
>
> I come from the Mac/Windows world.
>
> I'd like to know howm to check on the status of Apache via perl and what
> commands are possible to check on things like the listeners, DB connectivity.
>
> And if there are suggestions for places to read and learn, I'd appreciate them.
>
> Thanks in advance
>
> Russell Dobbins
> Verizon Wireless

Apache Variables

[Russell . Dobbins]

Let me start with "I'm new".

If this is the wrong forum, let me know now and please direct me to the right
place.

I come from the Mac/Windows world.

I'd like to know howm to check on the status of Apache via perl and what
commands are possible to check on things like the listeners, DB connectivity.

And if there are suggestions for places to read and learn, I'd appreciate them.

Thanks in advance

Russell Dobbins
Verizon Wireless

Re: Chaining SSI and gzip

[___cliff rayman___]

i think this is FAQ you are looking for:
http://thingy.kcilink.com/modperlguide/modules/Apache_OutputChain_Chain_Sta.html

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
Rodent of Unusual Size wrote:

> This is probably a FAQ, in which case I'll accept my wet-noodle
> lashings and follow any links provided.
>
> I'm trying to help someone who wants to use server-side includes
> AND send the result gzip-encoded.  Base Apache 1.3 can't do this, but
> I *think* this can be done with mod_perl and Apache::* modules (a
> mod_include emulator and a gzipper -- both of which exist, I'm sure),
> but a specific pointer to a recipe or an implementation example would
> be very welcome..
>
> And of course this is a rush job, and it's the end of the day.. :-(
> Thanks for forbearance, friends..
> --
> #kenP-)}
>
> Ken Coar
> Apache Software Foundation  
> "Apache Server for Dummies" 
> "Apache Server Unleashed"   

Chaining SSI and gzip

[Rodent of Unusual Size]

This is probably a FAQ, in which case I'll accept my wet-noodle
lashings and follow any links provided.

I'm trying to help someone who wants to use server-side includes
AND send the result gzip-encoded.  Base Apache 1.3 can't do this, but
I *think* this can be done with mod_perl and Apache::* modules (a
mod_include emulator and a gzipper -- both of which exist, I'm sure),
but a specific pointer to a recipe or an implementation example would
be very welcome..

And of course this is a rush job, and it's the end of the day.. :-(
Thanks for forbearance, friends..
-- 
#kenP-)}

Ken Coar
Apache Software Foundation  
"Apache Server for Dummies" 
"Apache Server Unleashed"   

Re: using modules written in C?

[Perrin Harkins]

On Thu, 17 Aug 2000, Mikael Claesson wrote:
> I plan to keep all lowerlevel database stuff in C, and
> embed it in a perl module. Will this make things run
> slower than if I made it all in perl?

It shouldn't.  Keep in mind though, when you use DBI from perl you are
still doing all the low-level database stuff in C.  DBI is all C code
with a perl interface.

Ultimately, most database applications under mod_perl have their
performance bottleneck at the database, which means you get a good return
on your effort by writing your application in the way that's easiest for
you to maintain (maybe in C, in your case) and then spending your
optimization time tuning the database and the SQL.

- Perrin

Re: Win32 compiling problem - unresolved external symbol

[Eric Cholet]

> Hello,
> 
>  I am attempting to compile Perl/Apache/mod_perl on Windows 2000 using
> MSVC6.
> Perl and Apache compiled fine however mod_perl returns the following error;
> 
> Configuration: ApacheModulePerl - Win32
> Release
> Linking...
>Creating library Release/ApacheModulePerl.lib and object
> Release/ApacheModulePerl.exp
> mod_perl.obj : error LNK2001: unresolved external symbol _ap_configtestonly
> Release/ApacheModulePerl.dll : fatal error LNK1120: 1 unresolved externals
> Error executing link.exe.

It's a bug in 1.24, pick up a cvs snapshot or delete the relevant lines in
src/modules/perl/mod_perl.c

-if (ap_configtestonly)
-GvSV_setiv(GvSV_init("Apache::Server::ConfigTestOnly"), TRUE);

--
Eric

Win32 compiling problem - unresolved external symbol

[Don Fike]

Hello,

 I am attempting to compile Perl/Apache/mod_perl on Windows 2000 using
MSVC6.
Perl and Apache compiled fine however mod_perl returns the following error;

Configuration: ApacheModulePerl - Win32
Release
Linking...
   Creating library Release/ApacheModulePerl.lib and object
Release/ApacheModulePerl.exp
mod_perl.obj : error LNK2001: unresolved external symbol _ap_configtestonly
Release/ApacheModulePerl.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

ApacheModulePerl.dll - 2 error(s), 0 warning(s)




I am following the procedures outlined in INSTALL.win32.  If anyone knows
how to
overcome the above error or recommend a better approach I would be most
grateful.

Thanks, Don

---
  Don Fike
  UTK::ICL
  [EMAIL PROTECTED]
  865-974-5511
---

Location Directive Problem

[Tony Whyte]

Running apache-1.3.11, mod_perl-1.24, irix6.5.5

this works: (gets handled by mod_perl)


  SetHandler perl-script
  PerlHandler Apache::Hello


this doesnt:


  SetHandler perl-script
  PerlHandler Apache::Hello


Tried quoting "/hello/world" I still get  "File does not exist:
/usr/local/apache/htdocs/hello/world" in logs.

Is there some other directive Ive missed or misconfigured.

Thanks

Tony

@INC still tainted :-(

[Dave Jenkins]

Hi,

Sorry if it's a breach of etiquette to re-post a query, and I'm doubly sorry if
it turns out to have been a particularly stupid question, but I've still not
found a solution or any clues. If I'm missing something obvious or just being
plain daft, feel free to mail me privately to avoid wasting more bandwidth!

Thanks,

Dave
--
Dave Jenkins
Silk New Media

--  Forwarded Message  --
Subject: Tainted @INC
Date: Tue, 15 Aug 2000 15:02:26 +0100
From: Dave Jenkins <[EMAIL PROTECTED]>


Hi,

I'd appreciate some help with a nasty little intermittent problem.

I'm running...
Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.9 OpenSSL/0.9.4
on a SuSE 6.2 box (2.2.10 kernel)

Mostly everything is fine, but now and then the following error appears. When
it does, it occurs every few requests, so presumably infects one or two of the
running Apache processes. It's cured by a restart (until the next time it
happens!)

[error] Insecure dependency in require while running with -T switch at 

The relevant line in  is a 'use' statement, such as
use Time::Local 'timegm';

I tried to find whether the problem was due to something dodgey getting into
@INC, by running the test script inctest.cgi, attached (is_tainted function
lifted from Camel book). If I run this after getting the above error message,
it indicates that every element of @INC is tainted.

I've looked at the "@INC and mod_perl" page in the guide. In httpd.conf I have
PerlTaintCheck On and I'm not setting PERL5LIB. My startup.pl doesn't do
anything with 'use lib'.

Thanks in advance for any advice,

Dave
--
Dave Jenkins
Silk New Media

 inctest.cgi

RE: Apache::ePerl

[Vladislav Safronov]

Hi!

;) see the benchmarks http://www.chamas.com/bench/index.html

/Vlad
 
> Can anyone say some words about perfomance issues of Embedded 
> Perl - ePerl
> (don't mix up with HTML::Embperl). I mean running under mod_perl using
> Apache::ePerl. Maybe anyone has done some perfomance testing?
> Thanx beforehand.
> 
> Sincerely yours,
> 
> Vladimir Buyanov, senior web-developer
> Agama Internet Systems
> http://www.aport.ru
> http://www.atrus.ru
> http://www.agama.com
> 
> 

mod_perl-1.24 - Make FAILS!

[Stephen Marriott]

Last few lines of make 
...
MOD_PERL mod_auth.c
cc -c  -I../../os/unix -I../../include   -DLINUX=2 -DMOD_PERL 
-DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED -D
MOD_PERL mod_setenvif.c
rm -f libstandard.a
ar cr libstandard.a mod_env.o mod_log_config.o mod_mime.o 
mod_negotiation.o mod_status.o mod_include.o mod_autoindex.o mod_dir.o
 mod_cgi.o mod_asis.o mod_imap.o mod_actions.o mod_userdir.o 
mod_alias.o mod_access.o mod_auth.o mod_setenvif.o
ranlib libstandard.a
<=== modules/standard
===> modules/perl
cc -O2 -Dbool=char -DHAS_BOOL -I/usr/local/include 
-I/usr/lib/perl5/5.00503/i386-linux/CORE -DMOD_PERL_VERSION=\"1.24\" 
-DMOD_PE
RL_STRING_VERSION=\"mod_perl/1.24\" -DNO_PERL_METHOD_HANDLERS=1 
-DNO_PERL_DIRECTIVE_HANDLERS=1 -DNO_PERL_SECTIONS=1 -DNO_PERL_SS
I=1  -I../../os/unix -I../../include   -DLINUX=2 -DMOD_PERL 
-DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED -DMO
D_PERL -c mod_perl.c
In file included from mod_perl.h:92,
 from mod_perl.c:67:
/usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of 
`union semun'
make[3]: *** [mod_perl.o] Error 1
make[2]: *** [all] Error 1
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/httpd_perl/apache_1.3.12/src'
make: *** [apache_httpd] Error 2


Perl version 5.005_03 built for i386-linux (2.0.36)

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
osname=linux, osvers=2.2.1-ac1, archname=i386-linux
uname='linux porky.devel.redhat.com 2.2.1-ac1 #1 smp mon feb 1
17:44:44 est 1999 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Built under linux
  Compiled at Apr  6 1999 23:34:07
  @INC:
/usr/lib/perl5/5.00503/i386-linux
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005

Any ideas?


--
Stephen Marriott - [EMAIL PROTECTED]
HiSOFT, The Old School, Greenfield, Bedford, MK45 5DE, UK
Tel: +44 1525 718181 Fax: +44 1525 713716 Freecall: 0500 223 660
http://www.hisoft.co.uk/ PGP public key on request.ICQ#:29793027
http://aist.co.uk/ http://cinema4d.co.uk/ http://speedyshop.com/
AFFILIATES NETWORK - http://www.hisoft.co.uk/cgi-bin/gp?pg=an.main

RE: Question about $sth->finish;

[Vladislav Safronov]

> On Tue, Aug 15, 2000 at 03:26:03PM +0400, Vladislav Safronov wrote:
> > Hi,
> > 
> > Could you have a look at the lines and answer the question ..
> > ---
> > sub foo {
> > my $dbh = shift;
> > 
> > my $sql = ...
> > 
> > my $sth = $dbh->prepare($sql);
> > $sth->execute;
> > $sth->finish;
> > }
> > ===
> > Do I always need to call $sth->finish?
> 
> You *never* need to call finish on non-select statements.
> (If you do, it's a driver bug.)
> 
> > Wouldn't it be automaticly called when
> > sub foo ends (when my variable $sth get destroyed)?
> 
> Finish marks the end of *fetching*, not the end of life of the handle.

So I can freely overwrite the handle with new one, since it's not the end
of life of the handle, can't I?
==
my $sql = "select .."
 
my $sth = $dbh->prepare($sql);
$sth->execute;
.. fetch just some (not all) data
my $newsql = "select .."
$sth = $dbh->prepare($newsql);
$sth->execute;
==
and this code should work with troubles ...

Vlad.

Re: using modules written in C?

[Stas Bekman]

On Thu, 17 Aug 2000, Barrie Slaymaker wrote:

> Mikael Claesson wrote:
> > 
> > with mod_perl it looks even better.
> 
> Cool.  Welcome.
> 
> > I plan to keep all lowerlevel database stuff in C, and
> > embed it in a perl module. Will this make things run
> > slower than if I made it all in perl?
> 
> Usually faster, but whether that's significant in your application
> (ie will the users notice) is hard to say.  It's primarily
> about productivity & maintainance vs. performance tradeoff.
> 
> XS code is a good way to preserve your existing code, I suspect.

XS or SWIG, you can find an introduction to both in the Advanced Perl
Programming book. 

For a wonderfull series of XS articles see: 
http://www.perlmonth.com/columns/modules/modules.html?issue=6
http://www.perlmonth.com/columns/modules/modules.html?issue=7
http://www.perlmonth.com/columns/modules/modules.html?issue=8
http://www.perlmonth.com/columns/modules/modules.html?issue=9
http://www.perlmonth.com/columns/modules/modules.html?issue=10

And of course: perldoc perl, which gives:

perlembed   Perl ways to embed perl in your C or C++ application
perlapioPerl internal IO abstraction interface
perlxs  Perl XS application programming interface
perlxstut   Perl XS tutorial
perlgutsPerl internal functions for those doing extensions
perlcallPerl calling conventions from C

[snipped the rest of nice comments]

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org

Re: Question about $sth->finish;

[Tim Bunce]

On Wed, Aug 16, 2000 at 08:26:09AM +0200, Henrik Tougaard wrote:
> From: Jay Jacobs [mailto:[EMAIL PROTECTED]]
> > On Tue, 15 Aug 2000, Tom Mornini wrote:
> > 
> > > It is my understanding of the DBI docs that you only need to call
> > > $sth->finish when you DON'T fetch all the rows that the 
> > $sth has ready to
> > > return.
> > > 
> > 
> > From "Writing Apache Modules with Perl and C":
> >   "You should still call finish() at the end of each series 
> > of fetches,
> > even though you are going to reuse the statement handler.  
> > Failure to do
> > so can lead to memory leaks."
> > 
> 
> You picked the wrong authority for this! The right place (tm) to look 
> when discussing DBI is 'perldoc DBI'. The relevant quote is:

> > If I remember correctly, it also frees up any resources used by the
> > database (depending on db) for the query, like for sorting, joining,
> > etc.  But I can't quote a source for that one.
>
> There is no authoritative source for that fallacy - I hope!

The right place (tm) to look when discussing DBI is 'perldoc DBI'. The
relevant quote is:

 $rc  = $sth->finish;
   
   [...]
   
   Consider a query like:
   
 SELECT foo FROM table WHERE bar=? ORDER BY foo
   
   where you want to select just the first (smallest) "foo" value from a
   very large table. When executed, the database server will have to use
   temporary buffer space to store the sorted rows. If, after executing
   the handle and selecting one row, the handle won't be re-executed for
   some time and won't be destroyed, the C method can be used to tell
   the server that the buffer space can be freed.

:-)

Tim.

Re: Question about $sth->finish;

[Tim Bunce]

On Tue, Aug 15, 2000 at 12:22:46PM -0500, Jay Jacobs wrote:
> 
> 
> On Tue, 15 Aug 2000, Tom Mornini wrote:
> 
> > It is my understanding of the DBI docs that you only need to call
> > $sth->finish when you DON'T fetch all the rows that the $sth has ready to
> > return.
> > 
> 
> >From "Writing Apache Modules with Perl and C":
>   "You should still call finish() at the end of each series of fetches,
> even though you are going to reuse the statement handler.  Failure to do
> so can lead to memory leaks."

Not true. Unless there's a driver bug, in which case anything can happen.

> If I remember correctly, it also frees up any resources used by the
> database (depending on db) for the query, like for sorting, joining,
> etc.  But I can't quote a source for that one.

Me. But it's only relevant if you're _not_ fetching _all_ rows.

> >From my point of view, it never hurts to call finish()...

True.

Tim.

Swish-e 2.0

[Bill Moseley]

There's a new beta version of swish-e that out and available for testing.
Much of the code was rewriting to protect against buffer overruns, and the
big changes are in indexing speed and the addition of phrase searches.
Indexing speed is much better (my little data set of 6000 files went from 6
minutes indexing time to about 30 seconds).

Jose Manuel Ruiz <[EMAIL PROTECTED]> has been handling most of the development.
 The beta is at his web site at 
   http://www.boe.es/swish-e/swish-e-2.0-beta4.tar.gz

I'd consider that release stable.

The real reason I'm posting this to the mod_perl list is that Jose has an
early release of a swish-e library and a basic perl module.  That's at 
   http://www.boe.es/swish-e/alpha/

I haven't heard anyone else on the swish-e list that's testing the library,
so maybe someone here could help.  I'm interested to see how well it does
when used under mod_perl (as I'm using the old swish under mod_perl and I
close my eyes whenever I get to the fork() in my code).

The swish-e home page is at http://sunsite.berkeley.edu/SWISH-E/



Bill Moseley
mailto:[EMAIL PROTECTED]

Re: Question about $sth->finish;

[Tim Bunce]

On Tue, Aug 15, 2000 at 03:26:03PM +0400, Vladislav Safronov wrote:
> Hi,
> 
> Could you have a look at the lines and answer the question ..
> ---
> sub foo {
>   my $dbh = shift;
> 
>   my $sql = ...
> 
>   my $sth = $dbh->prepare($sql);
>   $sth->execute;
>   $sth->finish;
> }
> ===
> Do I always need to call $sth->finish?

You *never* need to call finish on non-select statements.
(If you do, it's a driver bug.)

> Wouldn't it be automaticly called when
> sub foo ends (when my variable $sth get destroyed)?

Finish marks the end of *fetching*, not the end of life of the handle.

Reread the DBI 1.14 docs on finish and tell me if anything is unclear.

Tim.

p.s. If someone asked me what I'd change about the DBI I was to rewrite
it, I'd probably just say "rename finish to cancel_select".

Re: new cgi mod_perl question

[darren chamberlain]

Alex Menendez ([EMAIL PROTECTED]) said something to this effect:
> 
> does anyone know how to get the output of a standalone cgi script from a
> mod_perl module
> 
> I have tried all the subrequest stuff but I can't get it to work.

If all you are trying to do is get the raw output, use LWP and a virtual
server running on localhost:

# -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
package Apache::CGIGetter;

use vars qw($agent);
use constant HOST => 'http://localhost';

use Apache::Constants 'OK';
use LWP::UserAgent;
use HTTP::Request;

BGEIN { $agent = LWP::UserAgent->new(); }

sub handler {
my($r) = @_;
my $url = join '/',HOST,$r->uri;
if(my $args = $r->args) { $url .= "?$args"; }

# These lines are taken from pp. 376-377 of the Eagle book
# http://www.modperl.com/book/chapters/ch7.html#Handling_the_Proxy_Process_Ourse

my $request = HTTP::Request->new($r->method, $url);
$r->headers_in->do(sub { $request->header(@_) });
if($r->method eq 'POST') {
my $len = $r->header_in('Content-length');
my $buf;
$r->read($buf,$len);
$request->content($buf);
}

my $result = $agent->request($request);

# $cgi_content will contain the body of the resulting page, i.e.,
# the HTML page.
my $cgi_content = $result->content;

# Do stuff here with $cgi_content.

return OK;
}
# -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

In the httpd.conf:


SetHandler  perl-script
PerlHandler Apache::CGIGetter


And a virtual host on 127.0.0.1, running mod_cgi as usual.

Good luck.

(darren)

-- 
He who would trade liberty for safety deserves neither.

Re: using modules written in C?

[Barrie Slaymaker]

Mikael Claesson wrote:
> 
> with mod_perl it looks even better.

Cool.  Welcome.

> I plan to keep all lowerlevel database stuff in C, and
> embed it in a perl module. Will this make things run
> slower than if I made it all in perl?

Usually faster, but whether that's significant in your application
(ie will the users notice) is hard to say.  It's primarily
about productivity & maintainance vs. performance tradeoff.

XS code is a good way to preserve your existing code, I suspect.

> Will apache keep the module in memory between
> requests?

That's one of the primary advantages of mod_perl.  The other
(as I see it) is tight integration with Apache internals.

> Does this mean that I'll have to be more
> careful to free all memory that I allocate and such?

Very much so.

> No more cowboy coding?

'fraid not.

> There seems to be a module that keeps a constant mysql
> database connection open. Will this speed things up
> much? Can I use that connection in the C code (in the
> homegrown perl module)?

Yes, yes, and yes.  It might be too much of a pain to call into
perl from your C code, but you might be able to get the database
connection handle from DBI and pass it in to your C code.  Hard to
tell without knowing more about your C code and why it needs to
stay in C.  However, it should be pretty trivial to cache your
database connection yourself in your C code: just use your own
connection open routine that reuses the previous connection if
it's still valid, and never close.  That's probably easier.

Before going much further, you should probably read The Guide, as
it answers the questions you've asked (except the last) in great
detail, and more:

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

You might also get Writing Apache Modules with Perl and C, often
referred to as "the Eagle book", by Lincoln Stein and Doug MacEachern.

HTH,

Barrie


> 
> __
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/

using modules written in C?

[Mikael Claesson]

I've always done all my serious cgi-programming in C,
but now I've been forced to lern perl and I kinda
figure it's not that bad. And with mod_perl it looks
even better.

I plan to keep all lowerlevel database stuff in C, and
embed it in a perl module. Will this make things run
slower than if I made it all in perl?

Will apache keep the module in memory between
requests? Does this mean that I'll have to be more
careful to free all memory that I allocate and such?
No more cowboy coding?

There seems to be a module that keeps a constant mysql
database connection open. Will this speed things up
much? Can I use that connection in the C code (in the
homegrown perl module)?


__
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Apache::ePerl

[Vladimir Buyanov]

Hi all!

Can anyone say some words about perfomance issues of Embedded Perl - ePerl
(don't mix up with HTML::Embperl). I mean running under mod_perl using
Apache::ePerl. Maybe anyone has done some perfomance testing?
Thanx beforehand.

Sincerely yours,

Vladimir Buyanov, senior web-developer
Agama Internet Systems
http://www.aport.ru
http://www.atrus.ru
http://www.agama.com

Re: Persistent db with PerlRunOnce On?

[Perrin Harkins]

> Is it possible to establish db connection pooling with PerlRunOnce On?

No.  Technically Apache::DBI doesn't do "pooling" at all.  It simply keeps a
connection established within a child process open, in that child process.
Since PerlRunOnce On means each child will exit after serving a request, you
get no benefit at all from Apache::DBI.

- Perrin