date:20000815

On Tue, 15 Aug 2000, Doug MacEachern wrote:

> On Tue, 4 Jul 2000, Matt Sergeant wrote:
> 
> > Shouldn't DIR_MERGE be called when .htaccess files are found at different
> > levels, e.g:
> > 
> > /axkit/.htaccess
> > and
> > /axkit/test/.htaccess
> > 
> > I ask for /axkit/test/test.xsp
> > 
> > I would have expected it to ask for both .htaccess files and try and merge
> > the two using DIR_MERGE, but it doesn't. Am I missing something, or is
> > this expected functionality?
> 
> it's up to apache when dir_merge gets called.  do you see other apache
> config getting merged in that scenario?  i'm not sure what's supposed to
> happen in that case without testing.

I can't recall either now - but I don't seem to have a problem with it any
more...

Glad to see you're off read-only mode again :-)

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

RE: Question about $sth->finish;


> From: Vladislav Safronov [mailto:[EMAIL PROTECTED]]

> What can you say about this code? is it ok (overwriting 
> previous handle)?
> 
> ==
> sub foo {
>   my $dbh = shift;
> 
>   my $sql1 = "select *...
>   my $sql2 = "select *...
> 
>   my $sth = $dbh->prepare($sql1);
>   $sth->execute;
>   .. fetch some data.
> 
>   # should be $sth->finish inserted??
> 
>   $sth = $dbh->prepare($sql2); # we overwrite previous 
> handle saved in $sth
> ..
>   $sth->execute;
>   .. fetch some data.
>   return;
> }
> ==

$sth->finish should be inserted if (and ONLY if) the C<...fetch some data>
does NOT fetch ALL data in the select. If you do some thing like:
   while (my $r=$sth->fetchrow_arrayref) {
 .. handle data;
   }
there is no reason to call finish, but if you do
   while (...$sth->fetch..) {
   
   last if ;
   }
you will have to call finish, but I would reccomend using
another name for the second statement (that would help
the poor sod who will try to understand this in a years time :)

Henrik

RE: Question about $sth->finish;

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:

  finish
$rc  = $sth->finish;

  Indicates that no more data will be fetched from this statement handle
  before it is either executed again or destroyed.  It is rarely needed
  but can sometimes be helpful in very specific situations in order to
  allow the server to free up resources currently being held (such as
  sort buffers).

  When all the data has been fetched from a select statement the driver
  should automatically call finish for you. So you should not normally
  need to call it explicitly.

Note the last sentence!

> 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!

> From my point of view, it never hurts to call finish()...
Quite true. Do you also undef all your variables just before they go
out of scope? Thats comparable. There are a *few* situations where finish
is needed (Michael Peppler has shown one, the DBI docs list another) but
must DBI programmers won't need finish ever.

Henrik

Re: [OT]SegFaults, not PerlFreshRestart or module related


On Mon, 19 Jun 2000, Paul wrote:

> I'm running out of ideas.
> 
> PerlFreshRestart was completely unused, then explicitly set Off.
> I have two handlers, which seem to work well.  My logs report nothing
> amiss aside from the stream of segmentation faults killing off my
> server children, usually several in quick succession, then minutes or
> hours apart.  This makes me think it's usage-based (duh), but I can't
> seem to pin it down.
> 
> And there are no core files.  Shouldn't a segmentation fault that kills
> a process produce a core file?  What gives? I even logged in as root
> and did a "find / -name 'core'", in case it was dumping it in some
> obscure spot off the normal web directories.  Not a single hit.  We
> don't have gdb on this server, but I assumed it was GNUware and was
> going to install it -- but doesn't it need a core file?
> 
> I hate to even post this, but I'm completely baffled.
> I have users trying to hit the site from bookmarks, and getting the
> "document contained no data" popup; I can only assume it's my children
> segfaulting, and on no particular page.

core files might not be produced depending on the user your server runs
as, i think ulimit can change that or something, but don't know off the
top of my head.  if you can't reproduce the problem at will, attach to a
any apache child (make sure it's not the parent!) with gdb (see the
SUPPORT doc for hints) and wait for a segv.  then pass along `bt' and
`curinfo' to us.

Re: Seg fault (11) backtrace (long email) - was RE: does anyone havea fix for this?


On Thu, 3 Aug 2000, Jamie Krasnoo wrote:
 
> Program received signal SIGSEGV, Segmentation fault.
> 0x8086ef0 in perl_handler_ismethod ()

yes, cvs should fix this, here's the diff:

--- mod_perl.c  2000/05/25 18:06:23 1.121
+++ mod_perl.c  2000/06/02 17:23:07 1.122
@@ -1222,7 +1222,7 @@
 }
 
 #ifdef CVf_METHOD
-if (CvFLAGS(cv) & CVf_METHOD) {
+if (cv && (CvFLAGS(cv) & CVf_METHOD)) {
 is_method = 1;
 }
 #endif

Re: Apache::Include requires ExecCGI on doc root?


On Tue, 27 Jun 2000, Theo Petersen wrote:

> I was experimenting with Apache::Include and found something odd.  First
> I tried a document in htdocs that used a virtual include like so:
> 
> 
> 
> This works fine, and hello-mod_perl.pl runs via Apache::Registry.
> 
> But when I changed the include to use Apache::Include like so:
> 
> 
> 
> it didn't work, and I got an error in error_logs:
> 
> [Tue Jun 27 11:22:59 2000] [error] access to
> /usr/local/apache/perl/hello-mod_perl.pl failed for 192.168.3.9, reason:
> Options ExecCGI is off in this directory
> 
> I verified that ExecCGI is enabled for /usr/local/apache/perl (besides,
> the Apache::Registry version wouldn't have worked without it).  Turns
> out that Apache::Include worked fine when I enabled ExecCGI for htdocs.
> 
> Is there a reason why Apache::Include requires this when mod_include
> doesn't?

probably because Apache::Include skips the majority of the subrequest
mechanism and just calls $r->translate_name;  i don't know exactly what it
missing without looking, just stick with using mod_include's #include if
it's a problem.

Re: .htacess security


On Thu, 3 Aug 2000, Rob Giseburt wrote:

> Are .htaccess files secure?  I don't want users to be able to use
> ... sections or any other mod_perl constructs (setting scripts
> to run via the Registry, for example) in .htaccess files.  However, I need
> .htaccess files turned on so users can password protect directories
> site-wide (so I can't shut .htaccess files off completely.)

you can disable  by choosing explict options for Makefile.PL (rather
than EVERYTHING=1)

or change this line in mod_perl.h:
#define SECTION_ALLOWED OR_ALL

to:

#define SECTION_ALLOWED RSRC_CONF

p.s.
mod_perl-2.0 will let you disable things like so:


   PerlOptions -PerlSections

Re: does anyone have a fix for this?

On Wed, 2 Aug 2000, Jamie Krasnoo wrote:

> Hello all,
> 
> I'm new to the list and I'm hoping that someone could help me and explain
> what I'm doing wrong or how to fix this
> 
> 
> I recently compiled mod_perl-1.24 and it can run modules that I program.
> However I get a segmentation fault (11) when I use a :: to describe where
> the module is.

try mod_perl from cvs (see mod_perl_cvs.pod), this might be releated to
the perl_handler_is_method() fix.

Re: Client filehandle?


On Wed, 2 Aug 2000, Todd Caine wrote:

> > STDOUT is where $r->print goes under mod_perl; you should be OK.
> 
> The data that is printed out via $r->print is on the file descriptor that the
> http request is set up on.  If the HTTP request came in on file descriptor 3
> then $r->print('foo') prints to file descriptor 3; not stdout(file descriptor
> 1, on my system).

right, Perl STDOUT != C stdout
 
> The only way I can get part of gif to the browser was to do this:
> 
> my $c = $r->connection;
> my $fd_num = $c->fileno(0);
> open(STDOUT, ">&$fd_num");
> RRDs::graph($args);
> 
> But the data is incomplete.  Even when I autoflush the $fd_num.
> There has got to be a better way.

see Apache::Magick in the eagle book or at modperl.com.  it's still ugly
since it writes to a tmpfile, but it works.  you can also modify your c
sources to redfine stdout-ish calls, Apache::Peek does something like that
for redirecting stderr to the client socket:

#define PerlIO request_rec
#define PerlIO_printf rprintf
#define PerlIO_vprintf(r,fmt,vlist) \
 vbprintf(r->connection->client, fmt, vlist)
#define PerlIO_stderr() perl_request_rec(NULL)
#define PerlIO_putc(r,c) rputc(c,r)
#define PerlIO_puts(r,s) rputs(s,r)

Re: Customized Module For Logging In Transfer Log

2000-08-15 Thread Alan E. Derhaag

Saurabh Goyal <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I am new to apche and mod_perl. I am trying to write apache module to write
> some additional parameters to transfer log (access.log). Is anybody have an
> idea, how can we write additional stuff to access.log including the
> defaults. Any help appreciated.
> 
> Thanks,
> > SGoyal

You might look into Apache::DBILogger and subclass it more use it for
a template to begin with.

Re: Severe problem with $r->log_error


On Tue, 11 Jul 2000, Axel Wagner wrote:

> Hi,
> 
> I have a serious problem with the logging facility of MOD_PERL.
> Something that once worked perfectly well suddenly turned quite.
> 
> I have tried all the logging statements from the eagle book, but
> my error log file refuses to show any trace thereof.
> 
> I have also set the LogLevel to debug, but even with the following
> I do not succeed:
> 
> my $rlog = $r->log;
> $rlog->error('Message I try to print out');
> 
> nor with any of the following:
> 
> $r->log_error($msg);
> $r->log->error($msg);
> 
> Not even a $r->log->debug(); works.
> 
> Only a brute warn() leaves a trace.

what is your LogLevel set to in httpd.conf?

Re: crash in modperl-1.24

2000-08-15 Thread Mark D. Anderson


(not sure whose email got delayed since i posted this question some time ago --
thanks for the tip though on how to get more meaningful modperl crash info).

The problem was the symbol conflict between XML::Parser and apache when built
with expat. This has been apparently known for over a year, but has still not been
fixed last i checked, presumably because it involves 4 different products interacting:
apache builds with expat, modperl gets linked in, then modperl pulls in XML::Parser
which pulls in expat again.

I rebuilt apache disabling expat and all was fine.

This is so common a configuration (apache, modperl, and XML::Parser), i have
to assume that the only reason there is not rioting in the streets is because
perhaps it only happens the way i built it (apache statically linking modperl).

-mda

Re: (Fwd) Problem with Authen::Krb4 under mod_perl (fwd)


On Wed, 2 Aug 2000, Jeff Horwitz wrote:

> [forwarded just in case anyone else is having similar problems]
> 
> -- Forwarded message --
> Date: Wed, 2 Aug 2000 10:45:35 -0400 (EDT)
> From: Jeff Horwitz <[EMAIL PROTECTED]>
> To: Dave Edsall - The Tauminator <[EMAIL PROTECTED]>
> Subject: Re: (Fwd) Problem with Authen::Krb4 under mod_perl 
> 
> >First, thank you for responding and responding so quickly. The answer to 
> > your question is yes, we are using open_ssl so that we can encrypt the 
> > password being sent to the web server. But, if there are name clashes, why 
> > would the script work under mod_cgi and not mod_perl? We use ssl in both cases.
> 
> mod_cgi simply forks off separate processes.  with mod_perl, the scripts
> are interpreted and run in a Perl interpreter within apache.  Krb4.so is
> loaded just like any other shared library, and will conflict with apache
> if duplicate symbols exist.
> 
> >   Is there a way around the name clash problem?
> 
> yes.  build Authen::Krb4 with KTH Kerberos, available at
> http://www.pdc.kth.se/kth-krb.  it's a bit cleaner wrt the DES library,
> and it's much easier to build as well!  :)

you can also try the -Bsymbolic linker flag, which is supposed to force
Krb5.so so use the symbols in the libraries it linked against, rather than
those in the main program.  or try the approach below to lump the archives
directly into the .so, but change ssl stuff to krb stuff :)

--- Makefile.PL~Sat Jul 31 00:59:12 1999
+++ Makefile.PL Tue Aug  1 20:18:32 2000
@@ -61,12 +61,13 @@
 # See lib/ExtUtils/MakeMaker.pm for details of how to influence
 # the contents of the Makefile that is written.
 WriteMakefile(
+'OBJECT' => "SSLeay.o $openssl_path/lib/libssl.a $openssl_path/lib/libcrypto.a",
 'NAME'=> 'Net::SSLeay',
 'VERSION_FROM' => 'SSLeay.pm', # finds $VERSION
 'DEFINE'   => '', # e.g., '-DHAVE_SOMETHING' 
 'DISTNAME'  => 'Net_SSLeay.pm',
 'dist'  => { COMPRESS => 'gzip', SUFFIX => 'gz', },
-'LIBS' => ["-L$openssl_path -L$openssl_path/lib $libs"],
+#'LIBS'=> ["-L$openssl_path -L$openssl_path/lib $libs"],
 
 ### Win32 build: uncommend LIBS above and edit LIBS below according to your
 ###

Re: RRDs::graph and mod_perl

On Tue, 1 Aug 2000, Todd Caine wrote:

> I have Apache 1.3.12 installed on Solaris 2.7 running with
> mod_perl 1.24.  I have a simple mod_perl script, it actually
> uses Apache::Registry, that uses a Perl module called RRDs
> that can generate images/graphs from a round robin
> database.  If you pass it a '-' as a file name rrd_graph.c
> prints to 'stdout', or file descriptor 1.  Everything works
> just fine if I run the script using mod_cgi as the handler.
> But when using mod_perl I get a 200 response from the server
> but no data sent to the socket the request came in on.
> 
> I just install Perl 5.6 with sfio (safe and fast I/O).
> There was no difference in the way the script was handled.

RRDs::graph needs to use PerlIO_* for sfio to help.  if it's just calling
fwrite(..., stdout), then it bypasses the Perl/sfio layer.
i think there is an sfio stdio.h that you can #include in rrd_graph.c so
stdout will become sfio's stdout, but i haven't dealt with sfio in quite
sometime.

Re: User directive


On Tue, 1 Aug 2000, Rob Giseburt wrote:

> I want to modify the User cofiguration directive in a perl handler ... for
> example in a PerlTransHandler. I'm trying to use mod_perl to implement Named
> Virtual Hosting, and I have everything I need done except User and Group
> mapping so that SuEXEC will pick up the correct user and group to setuid the
> non-mod_perl CGI execution to. I cannot find what variable to change. I know
> that in a ... section it's simple $User, but in a
> PerlTransHandler context it seems you can only view it via $r->server->uid.
> Any suggestions?

you want to change the uid at request time?  the patch below will let you
say $r->server->uid($new_uid);

you'll have to maintain changing it back yourself, like so:

my $old_uid = $r->server->uid($new_uid);
$r->register_cleanup(sub { shift->server->uid($old_uid) });

i'm not sure if we should allow this or not, security implications?

--- src/modules/perl/Server.xs  1999/08/20 08:34:43 1.6
+++ src/modules/perl/Server.xs  2000/08/16 05:19:54
@@ -151,11 +151,16 @@
 RETVAL
 
 uid_t
-uid(server)
+uid(server, id=0)
 Apache::Server server
+uid_t id
 
 CODE:
 RETVAL = server->server_uid;
+
+if (items > 1) {
+server->server_uid = id;
+}
 
 OUTPUT:
 RETVAL

Re: Unexpected pnotes() behavior


pnotes() expects a reference, it probably should croak if it's passed
something else.  it just increments the reference count of the sv, it does
not make a copy.  if you don't want to use a reference, you can copy it
yourself:

$r->pnotes(key => "$string")

Re: Aborting Apache startup during PerlInitHandler

On Sun, 23 Jul 2000, Thomas Klausner wrote:

> Hi!
> 
> I have got a PerlInitHandler that does some config parsing etc.
> 
> I would like Apache to stop starting up and to print out some error
> message ("Config Directive blabla missing" or something like that) if
> an error occures during config parsing. (As it is happing when
> something is wrong with the Apache Config (httpd.cfg ...))
> 
> How can this be done?

PerlInitHandler?  that happens at request time, not startup time.
assuming you mean PerlRequire or PerlModule, just do something like so:

warn "config failed";
CORE::exit(1);

Re: segmentation fault with CGI::Application


On Wed, 19 Jul 2000, Michael J Schout wrote:

> I have been trying to get CGI::Application to work under mod_perl today.  So
> far with no success.
> 
> Finally I removed everything except CGI::Application from the config files, and
> the server dumps core on startup. 
> 
> I have a very stripped odwn httpd.conf that basically loads the bare minimum
> apache modules, then does "PerlModule CGI::Appliation".
> 
> Starting httpd dumps core when it tries to start up.
> 
> Running it through the debugger produces this:

i think this is one of the bugs fixed by the Perl patch (which will be 
in 5.6.1), see:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/dilkhumyox/[EMAIL PROTECTED]

the patch below to mod_perl might also fix it.

--- perl_util.c~Tue Jun 13 10:25:38 2000
+++ perl_util.c Tue Jun 13 11:16:45 2000
@@ -547,12 +547,14 @@
 {
 dTHR;
 SV *sv = sv_newmortal();
+COP *old_cop = curcop;
 dTHRCTX;
 
 sv_setpvn(sv, "require ", 8);
 MP_TRACE_d(fprintf(stderr, "loading perl module '%s'...", name)); 
 sv_catpv(sv, name);
 perl_eval_sv(sv, G_DISCARD);
+curcop = old_cop;
 if(s) {
if(perl_eval_ok(s) != OK) {
MP_TRACE_d(fprintf(stderr, "not ok\n"));

Re: Why can't I use a package name under Apache::Registry

On Tue, 11 Jul 2000, bill chmura wrote:

> 
> Hello,
> 
> I have a problem with using apache::Registry and have not been able 
> find an answer in the eagle book or the mod_perl site, so i am missing 
> something here.  
> 
> If I take the following script and run it under apache::registry it 
> runs fine:
> 
> #!/opt/perl5/bin/perl
> print "Content-type: text/html\n\n";
> exit;
> 
> If I throw a package name in there (like below) it still runs fine as a 
> standalone script and CGI script, but under apache::registry it 
> forwards an unrecognized header to the browser, which I cannot 
> determine what it is.  I have removed the package from the code, but 
> still wonder why I cannot do this?
> 
> #!/opt/perl5/bin/perl
> package myscript;
> print "Content-type: text/html\n\n";
> exit;

because Apache::Registry overrides Perl's builtin exit() in the compiled
script (which has it's own unique namespace).  you're calling exit() in a
different namespace, so exit() is now Perl's builtin exit.  the builtin
exit() calls a c-level exiting, killing the process before Apache's output
buffers have been flushed.
if you're using Perl 5.005+, exit() should be overridden everywhere, what
version are you using?

Re: crash in modperl-1.24


On Mon, 10 Jul 2000, Mark D. Anderson wrote:

> environment: linux redhat 2.2.12-20, modperl 1.24, apache 1.3.12
> 
> i've tried it with both perl 5.6 and with 5.005-03.
> in both cases, i get a segv crash almost immediately the first time i issue
> a request for a url using a perl handler (static file handling is fine).
> 
> below are the stack traces for the two perl versions, when run with -X .
> any suggestions for fixes or workarounds are very appreciated.
> (maybe building without EVERYTHING=1? who knows)

if you could do this:

% gdb httpd
(gdb) source mod_perl-x.xx/.gdbinit
(gdb) run -X
[make a request that core dumps]
(gdb) curinfo

should print the Perl filename:linenumber, posting a code window around
that area might shed some light.

Re: mod per compilation problem


On Wed, 5 Jul 2000, Kailashnath V Rampure wrote:

> This is with reference to ur mail on mod_perl APXS error w/ apache/raven to
> modperl mailing list.
> I have a problem same problem with mod_perl. I just removed the the -Wl, -E
> option from the flags of Make file for mod_perl but unable to compile
> mod_perl asa DSO.
> 
> I would like to know that were you able to compile mod_perl as a DSO on
> HP-UX 11 if so can let me know the steps you used to correct the problem.
> 
> 
> I have got the following error:
> 
> Apache istallation error:
> 
> ld -b -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo
> perl_util.lo perlio.lo mod_perl_opmask.lo  Apache.lo Constants.lo
> ModuleConfig.lo Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo
> Table.lo -Wl,-E -Wl,-B,deferred   -L/usr/local/lib
> /opt/perl5/lib/5.00503/PA-RISC2.0/auto/DynaLoader/DynaLoader.a -L/opt/perl5/
> lib/5.00503/PA-RISC2.0/CORE -lperl -lnsl -lnm -lndbm -ldld -lm -lc -lndir -l
> crypt
> ld: Unrecognized argument: -Wl,-E
> ld: Usage:  ld flags... files...

it looks like Perl's Config.pm is broken.  -Wl is meant for the compiler
(when used as LD), to pass arguments to the linker.  so, if you change:
-Wl,-E -Wl,-B,deferred

to -E -B deferred

it should work.  if you still have trouble, please post your 'perl -V'

Re: DIR_MERGE and .htaccess

On Tue, 4 Jul 2000, Matt Sergeant wrote:

> Shouldn't DIR_MERGE be called when .htaccess files are found at different
> levels, e.g:
> 
> /axkit/.htaccess
> and
> /axkit/test/.htaccess
> 
> I ask for /axkit/test/test.xsp
> 
> I would have expected it to ask for both .htaccess files and try and merge
> the two using DIR_MERGE, but it doesn't. Am I missing something, or is
> this expected functionality?

it's up to apache when dir_merge gets called.  do you see other apache
config getting merged in that scenario?  i'm not sure what's supposed to
happen in that case without testing.

Re: Undefined subroutine &Apache::RegistryNG->handler::handler


On Sun, 2 Jul 2000, Bill Moseley wrote:

> This question has come up before (and I've asked it before) and I'm still
> not sure of a solution.  It's been a while, so maybe someone else has seen
> (and solved) it?
> 
> I get about 20 or so of these errors every day out of say 10,000 request
> for this RegistryNG script.  I can't seem to make it happen, so I'm having
> a hard time tracking it down:
> 
>   Undefined subroutine &Apache::RegistryNG->handler::handler called at
>   /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm line 183.
> 
> The line number is not always the same on this error message.
> 
> Followed by that message -- often a few minutes (often three minutes) is
> 
>   Can't locate object method "handler" via package
>   "handler" at
>   /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm line 183.
> 
> 
> And this in the Apache error log at the same time as the second message above:
> 
>   child pid 9405 exit signal Segmentation Fault (11)
> 
> 
> Now, I am loading RegistryNG in startup.pl as has been suggested in the
> past.  
> 
>   use Apache::RegistryNG;
> 
> 
> This same problem happens with Apache::Registry, so it's not just RegistryNG.
> 
> I'm running on Apache/1.3.9 (Unix) mod_perl/1.21, which is a bit old (but
> it's it was updated to that version in an attempt to fix this problem).

you should upgrade to 1.24, there's been fixes since 1.21 that might be
related to your problem.

Re: recursion in Apache::Constants::AUTOLOAD?

2000-08-15 Thread Jim Winstead


On Aug 15, Doug MacEachern wrote:
> On Mon, 26 Jun 2000, Jim Winstead wrote:
> 
> > We were seeing some servers spin out of control (allocating memory
> > slowly) in Apace::Constants::AUTOLOAD (which apparently has been
> > reported in the mailing list before).
> > 
> > The attached patch fixes the problems for us. Could someone who
> > understands what is going on here shed some light?
> 
> ouch, how did you trigger this problem?  i don't see how that could
> happen Apache::Constants::__AUTOLOAD should always be defined inside
> httpd.  does this version of your patch prevent it?

good question. i have no idea what triggered it. and since our
patch seems to have cleared up the problem for us (which i think
we only ever saw on production servers), i'm reluctant to try a
new one.

perhaps it is related to this old problem:

http://marc.theaimsgroup.com/?l=apache-modperl&m=94528502827088&w=2

jim

Re: Apache 2 opportunity


On Sun, 2 Jul 2000, Francesco Pasqualini wrote:

> I think in the current version of modperl there is an important feature
> missing.
> At this time is not possible to share resources between apache childs and so
> we can not use "really" persistent DBI coneection.
> What I intend is the possibility to store a DBI connection in the $Session
> hash (Apache::ASP or Apache::Session).
> In this way we can start a DB connection for each user session and we can
> have different application upon differnet DB.
> The connection is started when the user session start, is maintenied in
> memory (in the apache main process ?),it is visible to the apache childs
> (threads) and is destroied at session end.
> 
> With the efforts (syntax tree sharing between threads) necessary to port
> modperl to apache 2, will be  possible to implement such a feature ?

it will be possible to share db connections between threads.  but 2.0 is
hybrid, there are still multiple processes, you cannot share db
connections between them, without something like DBD::Proxy.

Re: Cryptic Apache::Registry read() behavior


if anybody wants to confirm that this won't break anything (e.g. CGI.pm),
this patch will clear the buffer before appending to it.

--- Apache/Apache.pm2000/08/15 04:35:13 1.52
+++ Apache/Apache.pm2000/08/16 04:36:30
@@ -65,7 +65,7 @@
 my($nrd, $buf, $total);
 $nrd = $total = 0;
 $buf = "";
-$_[1] ||= "";
+$_[1] = "";
 #$_[1] = " " x $bufsiz unless defined $_[1]; #XXX?
 
 $r->hard_timeout("Apache->read");

Re: Cryptic Apache::Registry read() behavior


On Fri, 30 Jun 2000, Cyrus Rahman wrote:

> Hmm, I was just adapting a large application I wrote some years ago to work
> with mod_perl.  Much to my amazement, despite its complexity and the fact that
> it was largely written before mod_perl, it worked without modification!  Well,
> almost.  There is one problem:
> 
> When handling form uploads, it calls read() from perl and expects it to act
> just like the perl version.  But Apache.pm's read() does one notable thing
> differently.  If you do a 'read(STDIN, $buf, $size)', Apache.pm's read
> concatenates the new data to the previous contents of $buf instead of replacing
> it.
> 
> Now it is not that hard to clear the buffer before each read, but the unusual
> behavior breaks other things too, like the form uploads in CGI_Lite.  Is the
> concatenation an intentional feature, or is it a bug?

hmm, Apache::read() has not been touched for something like 2-3 years.  i
don't recall if it's a feature (e.g. something CGI.pm needs), so i
hesitate to change it at this point.
 
> Besides this it really is remarkable how perfectly mod_perl reproduces the CGI
> environment!

good news :)

Re: SIGPIPE errors


On Thu, 29 Jun 2000, Brent Meshier wrote:

> Occasionaly, during a GET/POST, the request will be
> dropped and netscape/IE returns "Document Contains No
> Data".  The errors logs report:
> 
> [modperl] caught SIGPIPE in process 18311 hint: may be a
> client (browser) hit STOP?
> [modperl] process 18311 going to Apache::exit with
> status=-2
> 
> When this happens, it will continue on for the next
> three or four sequential requests.
> 
> I also will see the webpage load with:
> Error: at
> /usr/lib/perl5/site_perl/5.005/i686-linux/Apache/SIG.pm
> line 31.
> 
> but not always during the SIGPIPE problems.
> 
> The modperl version is:
> Server Version: Apache/1.3.12 (Unix) PHP/4.0.0
> mod_perl/1.24
> Linux 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999
> i686 unknown
> PERL version 5.005_03 built for i686-linux

Apache::SIG is no longer enabled by default with apache_1.3.6+, do you
have it configured somewhere?  take it out of your config and things
should be fine.

Re: getting data posted to site

On Thu, 29 Jun 2000, Scott Alexander wrote:

> I'm trying to get the data that is posted from the browser durring a 
> request.
> 
> if ($r->method ne 'GET')
> {
>   $r->read($buffer,$r->header_in('Content-Length'));
>   #proccess data...
> }
> 
> The $r->read() hangs the request completely.  I ran an strace on 

that normally happens because somebody already read the POST body.  are
you still having this problem?  the best way to figure out who is doing
this would be to use gdb:

% gdb httpd
(gdb) b ap_get_client_block
(gdb) source mod_perl-x.xx/.gdbinit
(gdb) run -X

now make a request:
(gdb) curinfo

should show the current Perl filename:linenumber

continue:
(gdb) c

and use curinfo the next time the breakpoint is hit.

Re: does END at the end save memory?

On Thu, 29 Jun 2000, Vladislav Safronov wrote:

> Hi, 
> 
> Does __END__ directive at the end of every mod_perl script
> reduce memory used by httpd ?

in a module, no.  in an Apache::Registry script, __END__ blocks are not
supported.  if they were, __END__ would consume more memory to maintain
the *DATA filehandle.

Re: CHECK blocks under mod_perl?

On Wed, 28 Jun 2000, Michael J Schout wrote:

> Hi.
> 
> I would like to use a CHECK { } block under mod_perl, but have so far not had
> any luck.  It seems like mod_perl does not know how to deal with CHECK { }
> blocks.  Is this true?  If so, can it be remedied?   I cant use a BEGIN block
> for what I am doing because it must happen after compilation is completed.  I
> know that CHECK blocks are a 5.6.0 feature so this is why I think maybe
> mod_perl doesnt know how to deal with them.

Perl only calls CHECK blocks during perl_parse(), which mod_perl calls
once at startup time.  so CHECK blocks don't work for the same reason this
doesn't:
% perl -e 'eval qq(CHECK { print "ok\n" })'

can you give an example of what you're trying todo?  it might be
reasonable to fit this into Apache::Registry, which already has to special
case END blocks.  i'd rather not add another special case, but if there's
good reason, it shouldn't be difficult to implement.

Re: Apache::Config module

On Tue, 27 Jun 2000, Nathan Wiger wrote:

> Hi all-
> 
> I've written a module that can parse the Apache httpd.conf config file
> (and in fact any Apache-like config file). It will take a set of
> directive like:
> 
>  ServerName www.mydomain.com
>  UseCanonicalName   Off
>  
> And parse it case-insensitively, returning a ref to a hash:
> 
> my $ac = new Apache::Config;
> my $conf = $ac->readconf($configfile);
> print $conf->{servername};   # = "www.mydomain.com";
> print $conf->{usecanonicalname}; # = 0   (not undef so can test
>  #for defined() still)

it would be really cool if this module could support dumping of a parsed
config file into the same format that  sections understand.  and the
other way around, dumping a  section back into a .conf that Apache
can read without  sections.

> In any case, I have several questions:
>  
> 1. Does a module like this exist anywhere?  I saw Doug's
>Apache::httpd_conf, but this only takes care of writing
>a very minimal config file. I looked thru all the
>Apache:: modules but didn't see one.

yeah, Apache::httpd_conf was something that was started and never
finished.  i think ken williams is working on something in this area, for
modules to write test config files.

> 2. Is the name Apache::Config a good name for this module?
>It seems like the obvious choice to me, and doesn't
>look like it's taken. I've also played around with
>Apache::ConfigFile and Apache::ReadConf, either of
>which I'm open to as well (or other suggestions?).

i'd go with Apache::ConfigFile.

Re: recursion in Apache::Constants::AUTOLOAD?


On Mon, 26 Jun 2000, Jim Winstead wrote:

> We were seeing some servers spin out of control (allocating memory
> slowly) in Apace::Constants::AUTOLOAD (which apparently has been
> reported in the mailing list before).
> 
> The attached patch fixes the problems for us. Could someone who
> understands what is going on here shed some light?

ouch, how did you trigger this problem?  i don't see how that could
happen Apache::Constants::__AUTOLOAD should always be defined inside
httpd.  does this version of your patch prevent it?

--- Constants/Constants.pm  2000/03/03 20:42:01 1.20
+++ Constants/Constants.pm  2000/08/16 04:05:45
@@ -18,7 +18,7 @@
 #outside of mod_perl this will recurse looking for __AUTOLOAD, grr
 *AUTOLOAD  = sub {
#why must we stringify first???
-   __AUTOLOAD() if "$Apache::Constants::AUTOLOAD"; 
+   __AUTOLOAD() unless $Apache::Constants::AUTOLOAD =~ /__AUTOLOAD$/;
goto &$Apache::Constants::AUTOLOAD;
 };
 }

RE: set_handlers() bug?


On Mon, 26 Jun 2000, Geoffrey Young wrote:
 
> IIRC, Doug agreed to take a look at get/set handlers issues 'soonish' :)

i guess this is later than 'soonish', sorry ;-/

Re: -DDL_UNLOAD_ALL_AT_EXIT ?

On Mon, 26 Jun 2000, Mikhail Zabaluev wrote:

> Hello,
> 
> I'm interested to know, does the DL_UNLOAD_ALL_AT_EXIT compilation flag
> for Perl 5.6.0 affect mod_perl's behaviour in any way? 'man perldelta'
> says that it might.

no, it was designed to, but mod_perl implements the feature in it's own
way so it'll work with older Perls too.

Re: Segfault in perl_handler_ismethod


On Mon, 26 Jun 2000, Rich Williams wrote:

> 
> Hi,
> 
> Linux 2.2.14, Apache 1.3.12, Perl 5.6.0, mod_perl 1.24.
> 
> On the first request, I get a segfault after perl_handler_ismethod
> is called.
> 
> #0  0x40280fdc in mod_perl_register_cleanup (r=0x92ba3fc, sv=0x1) at mod_perl.c:1242
> #1  0x40280fb0 in perl_handler_ismethod (pclass=0x92ba3fc, sub=0x1 of bounds>) at mod_perl.c:1236

this is a strange looking stacktrace, but this might be fixed in cvs with
this change:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet <[EMAIL PROTECTED]>]

Re: Group authorization information in a downstream chained handler


On Thu, 22 Jun 2000, Christian Gilmore wrote:

> I'm trying to create a cache for group authorization. I'm wondering if
> there's any way I can alter the requires information during the initial
> authorization so that the cache building code can just pick from that which
> group this person matches instead of re-authorizing during cache creation.
> 
> I'd like for the actual authorization handler to not need necessarily to be
> tied to a cache, so doing the entire authorization and caching in one module
> is not optimal, IMO. I'm going for the following (printed below on multiple
> lines just for readability):
> 
>   PerlAuthzHandler
>   Tivoli::Apache::AuthzCache
>   Tivoli::Apache::AuthzLDAP
>   Tivoli::Apache::AuthzCache::manage_cache
> 
> If the require line contains more than one group, I don't believe that I, by
> default, have any way to know, even after AuthzLDAP has completed
> successfully, of which group the client user is a member.
> 
> Any ideas? I intend to release all of these cache and LDAP auth modules when
> complete and put through some testing internally.

you can override the 'requires' directive using directive handlers, you'll
just need to manage the structure yourself.

Re: Apache::Util problem


On Wed, 21 Jun 2000, Joel Bremson wrote:

> All of a sudden I'm getting an error when
> I use Apache::Util. It was working fine,
> and then stopped. I've isolated the
> module from my code and still get the error.
> 
> Apache is 1.3.6 and perl is 5.00503.

what version of mod_perl?
 
> 
> This is the module:
> 
> package iSyn::Apache::foo;
> 
> use Apache::Util qw(escape_uri);
> 
> 
> This is the compile result:
> 
> pris-517:perl -wc foo.pm
> Can't locate object method "boot" via package "mod_perl" at
> /p/server/perl5.005_03/lib/site_perl/5.005/sun4-solaris/Apache/Util.pm
> line 19.
> BEGIN failed--compilation aborted at foo.pm line 3.  

seems like the wrong mod_perl.pm is picked up, you should be able to
syntax check outside of httpd:
% perl -ce 'use Apache::Util ();'
-e syntax OK

that's part of the reason mod_perl::boot() exists, so bootstrap of the c
symbols are not attempted outside of httpd.

Re: Multiple module configuration directive problem


On Wed, 21 Jun 2000, Rob Tanner wrote:

> Solved my own problem -- read other modules config with:
> 
>Apache::ModuleConfig->get($r, 'Apache::other_module')
> 
> Since that means each module has to figure out whether it's reading it's 
> own directives or it's neighbors, this mechanism in this case is kind of 
> cludgy.  Can I get both modules to actually read the same directives?

two modules can read the same directive if the first returns
Apache::Constants::DECLINE_CMD

Re: Pages stopping and not loading completely...


On Mon, 19 Jun 2000, Matt Sergeant wrote:

> On Mon, 19 Jun 2000, Farley, Scott wrote:
> 
> > I'm running an application Apache + mod_perl that connects to an MySQL
> > database and the pages every so often decide not fully load.  You can even
> > see the the HTML printed to the screen sometimes because the stream is
> > broken in the middle.  Some of the error messages include:
> > 
> > [Mon Jun 19 11:07:33 2000] [info] mod_perl: Apache->print timed out for
> > xxx.xxx.xxx.xxx
> > [Mon Jun 19 11:07:33 2000] [debug] Apache.xs(1040): mod_perl: rwrite
> > returned -1
> 
> Its a long fixed bug. Upgrade your mod_perl.

no, the bug that was fixed was the explosion of endless 'mod_perl: rwrite
returned -1' messages.  it is still possible to see that error if LogLevel
is set to debug and ap_rwrite() fails.

Re: Segfault Apache1.3.12/mod_perl1.24/Solaris2.6


On Mon, 19 Jun 2000, G.W. Haywood wrote:

> Hi Eric,
> 
> > > [Fri Jun 16 17:20:21 2000] [notice] \
> > > child pid 22310 exit signal Segmentation Fault (11)
> 
> On Mon, 19 Jun 2000, Eric Cholet wrote:
> 
> > backtrace.
> 
> (gdb) bt
> #0  0x2b444 in perl_handler_ismethod ()
> #1  0x2c43c in perl_call_handler ()
> #2  0x2bd5c in perl_run_stacked_handlers ()
> #3  0x29920 in perl_handler ()
> #4  0x7fce8 in ap_invoke_handler ()
> #5  0x9bdfc in ap_some_auth_required ()
> #6  0x9be7c in ap_process_request ()
> #7  0x8fbac in ap_child_terminate ()
> #8  0x8fe14 in ap_child_terminate ()
> #9  0x90014 in ap_child_terminate ()
> #10 0x908f4 in ap_child_terminate ()
> #11 0x914a0 in main ()
> 
> Curiously enough, Apache::Registry seems to run ok with a simple
> "Hello world" type of script.  Stay tuned.

if you haven't tried already, this bug has been fixed in cvs for quite a
while:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet <[EMAIL PROTECTED]>]

Re: Can anybody explain this?


On Sat, 17 Jun 2000, Rob Tanner wrote:

> Here's the scenario:
> 
> I have a modperl program I've been working on for a while (my first, so I'm 
> a newbie).  I was having problem getting php to run and discovered that if 
> modperl was configured, it ran fine.  But it wasn't my immediate priority, 
> so I let it slide.  This evening, I discovered a similar problem with 
> cgi-bin scripts.  I found that if my modperl script is sandwiched in a 
>  directive, everything works as advertised (cgi and 
> php).  In otherwords:
> 
> 
>   SetHandler perl
>   PerlHandler Apache::foofoo
> 
> 
> But if I remove the location directive (the module looks at $r->filename to 
> see if it's the object of the get request), it all breaks again -- i.e., 
> cgi and php, the module works in either case.  This is even true if the 
> very first statement in the module is "return DECLINED;" which should not 
> be necessary since the perl module shouldn't even see the cgi request.  And 
> just to satisfy myself, I confirmed that assumption absolutely with a 
> couple of print statements to STDERR (prints to the error_log).
> 
> What is actually going on here?  I loose some useful but not essential 
> functionality by using location and/or directory directives, and I would 
> prefer not to.  What do I need to do to fix it?

the problem is that without the , SetHandler perl-script applies
to every request, only mod_perl can handle that type, so returning
DECLINED doesn't help.  you'd be better off with a PerlFixupHandler (and
no SetHandler perl-script), let the FixupHandler decide if the request
should be handled by mod_perl, and if so:
$r->handler('perl-script');
$r->push_handlers(PerlHandler => \&Apache::foo);

RE: Apache children hanging


On Tue, 13 Jun 2000, Paul G. Weiss wrote:

> Yes, that much I knew, however when you do that you
> can't use curinfo from .gdbinit, because the process
> is not running.

> > % gdb httpd core

that's worked with curinfo for me in the past.

Re: Big pages and gzip


On Sat, 10 Jun 2000, Ken Williams wrote:

> Darn.  Or perhaps: cool.  Is it possible for me to usurp this module?
> The Apache::Gzip module I've been working on has the same goals and same
> purpose as the one in the eagle, but a bit of a different interface and
> a very different implementation inside.  It's reasonable that if the
> only thing changing is the interface (can I say that with a straight
> face?), the module could be kept the same.  Doug, what do you think?
> 
> I assume it would be a bad idea to have two modules, an Apache::GZip
> (from the book) and an Apache::Gzip (on CPAN).  Or might that be okay,
> if notes were added to the docs for each?

how about calling it Apache::GZipStream ?  you can borrow whatever you
like from the book example.

Re: $r->set_handlers behavior?

On Wed, 26 Apr 2000, Geoffrey Young wrote:

> good morning...
> 
> I'm a bit confused about $r->set_handlers and $r->push_handlers behavior.
> Both are listed in the eagle book as being per-request methods, but man
> Apache lists them both as server configuration directives.  I think, though,
> that I'm seeing set_handlers as persisting with the child and push_handlers
> as being per-request.  Personally, I'd rather have set_handlers per-request
> as well for situations where I want to add a handler but reorder it with the
> existing ones as well...

the {get,set}_handlers patch posted earlier should fix this behavior, can
you confirm?  push_handlers() should probably also be implemented in terms
of r->per_request_config, rather than %Apache::PerlStackedHandlers.

Re: $r->get_handlers bug/oversight?

On Tue, 25 Apr 2000, Geoffrey Young wrote:

> Hi all...
>   
>   I've noticed that get_handlers() will return the enabled handlers
> for a PerlPostReadRequestHandler, but not when it is specified as a
> PerlInitHandler (either by calling
> $r->get_handlers('PerlPostReadRequestHandler') or
> $r->get_handlers('PerlInitHandler').  It is the same with
> PerlHeaderParserHandler.  An oversight?

PerlInitHandler is just an alias for PerlPostReadRequestHandler and
PerlHeaderParserHandler.  mod_perl can only know at config-time if
InitHandler should be alias to PostReadRequest or HeaderParser, i don't
think get_handlers() can figure out which you mean at request time.

>   Also, I can't get anything for PerlCleanupHandlers, which kinda
> makes sense, since Cleanup isn't really a phase, per se (at least according
> to the book).  Does it make sense to add this to get_handlers() as well?

the get_handlers() patch posted earlier should enable get/set of
PerlCleanupHandlers.

Re: Totally trivial patch


On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote:

> Hi Doug,
> 
>   I was trying to figure out how to hide part of the URL of an 
> $r->custom_response from the user and I found this...
> 
> It's real trivial, does that matter?

not at all, more than welcome, thanks.
 
> I assume that if (*string == '/') then of course (*string != '"').
> I am also assuming that || and && work the same in .xs as they would in perl.

yep.
 
> This is a patch against the current CVS.
> 
> --- Apache.xs   Mon Jun  5 18:20:44 2000
> +++ Apache.xs.new   Mon Jul 10 11:41:47 2000
> @@ -264,7 +264,7 @@
>  retval = conf->response_code_strings[idx];
>  if (string) {
> conf->response_code_strings[idx] =
> -   ((is_url(string) || (*string == '/')) && (*string != '"')) ?
> +   ((is_url(string) && (*string != '"')) || (*string == '/')) ?
> pstrdup(r->pool, string) : pstrcat(r->pool, "\"", string, NULL);
>  }
> 
> 
> 
> By the way, I know (and am sorry about) the fact that you all have spent
> more time reading about this than all the CPU cycles this patch will ever
> save combined, I think.  And maybe every known compiler sees the issue and
> compiles both versions the same way, anyway.

i'm not sure how much it would save, or if compilers would optimize that.
but, feel free to pass along anything else like this, even if it seems
trivial.

Re: Pinning down panic: POPSTACK


On Wed, 28 Jun 2000 [EMAIL PROTECTED] wrote:

> The modperl archives are pretty clear that
>   panic: POPSTACK errors
> caused by dies called in a eval is a perl bug.
> 
> The archives are also clear that this is often a result
> of an interaction with Apache::Session, which I *was*
> getting, but have since fixed(?)

yes, fixed in Perl 5.6.0.

> My new problem is that I am getting the error
> between my PerlAccessHandler and HTML::Mason module.
> I repeat, the PerlAccessHandler is completely done, and
> the HTML::Mason handler hasn't been called at all.
> This is NOT a case of a tied Apache::Session going out
> of scope when the PerlAccessHandler ends.
> I think I proved this by putting debugging lines in
> subs DESTROY and 'save' of Apache::Session.pm.
> 
> That's what my problem USED to be. :)
> 
> Doesn't this mean it is happening in mod_perl itself?

maybe, are you still having this problem?  if you can reproduce it, start
httpd like so:

% gdb httpd
(gdb) b Perl_my_exit
(gdb) run -X

then make a request that triggers the POPSTACK error, go back to gdb:

(gdb) where

and post the output of that.

Re: [OT] mod_proxy tuning info?

2000-08-15 Thread Perrin Harkins


Hi Ed,

> * What affect does CacheGcInterval have on performance?

You might find it useful to split GC out into a separate process,
especially if you are sharing the cache directory over NFS.

> * How does performance scale with 1GB, 2GB, or 4GB of memory?

Your filesystem performance should improve with more memory, so I would
expect mod_proxy performance to improve as a result.

> * There are dynamic pages I want cached for a certain TTL. There are other
> dynamic pages I don't want cached at all. Do I have to use the NoCache
> directive on all the directories/files I don't want cached? Or is there a
> more effective way to do this?

You can do it with Expires headers.  Make sure you send Last-Modified or
the pages won't get cached.  If you don't want the rest of the world to
get your Expires headers, you'll have to modify mod_proxy to remove them.

- Perrin

Memory Leak

2000-08-15 Thread vegan.star


I have some mod_perl modules. I suspect that it has a memory
leak. I'm running that in a Sun Solaris 2.6 machine with apache
1.3.9. I read that exists Apache::Leak to test for leaks.
How it works?
I have some packages and I put into them like this:

package package_name;
use Apache::Leak;

leak_test{


sub handler
{
 statements
}

sub another_function
{
  statements
}
};

Is it correct? I thought not, because the answers are always no
leaks.

Anybody can helps me? Another idea to detect the leaks?

Regards,

Alex


__
BOL dá 15 viagens GRÁTIS para as Olimpíadas!
Desafio BOLimpíadas. Inscreva-se já! http://desafio.bol.com.br/bolimpiadas

Re: [OT] mod_proxy tuning info?

2000-08-15 Thread Edward Moon

Yes, I have read that part of the mod_perl guide. I'm looking for a more
detailed discussion on mod_proxy configuration and performance.

But it doesn't answer the questions I have regarding the use of mod_proxy:
* What affect does CacheGcInterval have on performance?
* Does setting CacheDirLevels to a high value cause a performance hit?
* Does setting CacheDirLength to a small value increase performance?
* How does performance scale with 1GB, 2GB, or 4GB of memory?
* How do you determine the overall hit rate? The hit rate from ram? The
hit
rate from disk?
* There are dynamic pages I want cached for a certain TTL. There are other
dynamic pages I don't want cached at all. Do I have to use the NoCache
directive on all the directories/files I don't want cached? Or is there a
more effective way to do this?

On Tue, 15 Aug 2000, ___cliff rayman___ wrote:

> have u read this yet?
> http://perl.apache.org/guide/scenario.html#mod_proxy
> 
> Edward Moon wrote:
> 
> > I'm looking for docs or white papers on tuning apache/mod_proxy for
> > optimum performance when acting as a reverse proxy for a web farm.
> >
> > Can anyone point me to a URL or a book that's a good reference?
> >
> > Thanks,
> 
> --
> ___cliff [EMAIL PROTECTED]http://www.genwax.com/
> 
>

Filter::decrypt under mod_perl??

2000-08-15 Thread Leonardo Madrigal


Hi!

Does any body knows if Filter::decrypt works under mod_perl..

i only get "unrecognized character" on the log files, but on the 
commmand line they work...

thanx

--Leo.

Re: Yet more on set_handlers() and new-found problems with lookup_uri()


i think the jist of the problem(s), is that set_handlers() modifies the
configuration structure (the one created at startup from httpd.conf), so
any subrequests will end up with the modified structure (which is not
reset until the end of the request).  this patch implements
{get,set}_handlers in terms of r->per_request_config, which is
unique to each (sub-)request.  if this doesn't fix the problem, it would
really help to have a small test case that i can drop in to see the bug in
action.

Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.103
diff -u -r1.103 Apache.xs
--- src/modules/perl/Apache.xs  2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs  2000/08/16 00:46:44
@@ -73,12 +73,6 @@
 void (*set_func) (void *, void *, SV *);
 } perl_handler_table;
 
-typedef struct {
-I32 fill;
-AV *av;
-AV **ptr;
-} perl_save_av;
-
 static void set_handler_dir (perl_handler_table *tab, request_rec *r, SV *sv);
 static void set_handler_srv (perl_handler_table *tab, request_rec *r, SV *sv);
 
@@ -101,28 +95,17 @@
 {HandlerDirEntry("PerlFixupHandler", PerlFixupHandler)},
 {HandlerDirEntry("PerlHandler", PerlHandler)},
 {HandlerDirEntry("PerlLogHandler", PerlLogHandler)},
+{HandlerDirEntry("PerlCleanupHandler", PerlCleanupHandler)},
 { FALSE, NULL }
 };
 
-static void perl_restore_av(void *data)
-{
-perl_save_av *save_av = (perl_save_av *)data;
-
-if(save_av->fill != DONE) {
-   AvFILLp(*save_av->ptr) = save_av->fill;
-}
-else if(save_av->av != Nullav) {
-   *save_av->ptr = save_av->av;
-}
-}
-
 static void perl_handler_merge_avs(char *hook, AV **dest)
 {
 int i = 0;
 HV *hv = perl_get_hv("Apache::PerlStackedHandlers", FALSE);
 SV **svp = hv_fetch(hv, hook, strlen(hook), FALSE);
 AV *base;
-
+
 if(!(svp && SvROK(*svp)))
return;
 
@@ -133,45 +116,53 @@
 }
 }
 
+#define avptr_from_offset(ptr, tab) \
+(AV **)((char *)ptr + (int)(long)tab->offset)
+
 static void set_handler_base(void *ptr, perl_handler_table *tab, pool *p, SV *sv) 
 {
-AV **av = (AV **)((char *)ptr + (int)(long)tab->offset);
+int do_register_cleanup = 0;
+AV **av = avptr_from_offset(ptr, tab);
 
-perl_save_av *save_av = 
-   (perl_save_av *)palloc(p, sizeof(perl_save_av));
-
-save_av->fill = DONE;
-save_av->av = Nullav;
-
-if((sv == &sv_undef) || (SvIOK(sv) && SvIV(sv) == DONE)) {
-   if(AvTRUE(*av)) {
-   save_av->fill = AvFILL(*av);
-   AvFILLp(*av) = -1;
-   }
-}
-else if(SvROK(sv) && SvTYPE(SvRV(sv)) == SVt_PVAV) {
-   if(AvTRUE(*av))
-   save_av->av = av_copy_array(*av);
-   *av = (AV*)SvRV(sv);
-   ++SvREFCNT(*av);
+if ((sv == &sv_undef) || (SvIOK(sv) && SvIV(sv) == DONE)) {
+if (!*av) {
+do_register_cleanup = 1;
+}
+if (*av && SvREFCNT(*av)) {
+SvREFCNT_dec(*av);
+}
+*av = newAV();
+}
+else if (SvROK(sv) && SvTYPE(SvRV(sv)) == SVt_PVAV) {
+*av = (AV*)SvRV(sv);
+++SvREFCNT(*av);
+do_register_cleanup = 1;
 }
 else {
-   croak("Can't set_handler with that value");
+croak("Can't set_handler with that value");
+}
+
+if (do_register_cleanup) {
+register_cleanup(p, (void*)*av, mod_perl_cleanup_av, mod_perl_noop);
 }
-save_av->ptr = av;
-register_cleanup(p, save_av, perl_restore_av, mod_perl_noop);
 }
 
-static void set_handler_dir(perl_handler_table *tab, request_rec *r, SV *sv)
+void set_handler_dir(perl_handler_table *tab, request_rec *r, SV *sv)
 {
-dPPDIR; 
-set_handler_base((void*)cld, tab, r->pool, sv);
+dPPREQ;
+if (!cfg->dir_cfg) {
+cfg->dir_cfg = perl_create_dir_config(r->pool, r->uri);
+}
+set_handler_base((void*)cfg->dir_cfg, tab, r->pool, sv);
 }
 
 static void set_handler_srv(perl_handler_table *tab, request_rec *r, SV *sv)
 {
-dPSRV(r->server); 
-set_handler_base((void*)cls, tab, r->pool, sv);
+dPPREQ;
+if (!cfg->srv_cfg) {
+cfg->srv_cfg = perl_create_server_config(r->pool, NULL);
+}
+set_handler_base((void*)cfg->srv_cfg, tab, r->pool, sv);
 }
 
 static perl_handler_table *perl_handler_lookup(char *name)
@@ -185,29 +176,45 @@
 return NULL;
 }
 
-
 static SV *get_handlers(request_rec *r, char *hook)
 {
 AV *avcopy;
 AV **av;
+dPPREQ;
 dPPDIR;
 dPSRV(r->server);
 void *ptr;
 perl_handler_table *tab = perl_handler_lookup(hook);
 
-if(!tab) return Nullsv;
+if (!tab) {
+return Nullsv;
+}
 
-if(tab->type == PER_DIR_CONFIG)
-   ptr = (void*)cld;
-else
-   ptr = (void*)cls;
+if (tab->type == PER_DIR_CONFIG) {
+if (cfg->dir_cfg && *avptr_from_offset(cfg->dir_cfg, tab)) {
+ptr = (void*)cfg->dir_cfg;
+}
+else {
+

Re: Persistent db connectivity

2000-08-15 Thread Jie Gao


On Tue, 15 Aug 2000, Pramod Sokke wrote:

> I mentioned that I'm using Apache::Sybase::CTlib and not Apache::DBI for
> persistent connectivity. Moreover, if the module is not declared and I try
> to connect in the startup file, the server won't even start. So that's
> obviously taken care of.
> My question is more of, how do I know for sure that my server is using the
> already opened connection and is not trying to make fresh connections on
> every call to 'Connect'? The error logs say : [notice] Establishing
> connection to PURCHASEDB:purchasedb.
 
I don't think Apache::DBI works with Apache::Sybase::CTlib. You need a 
separate module for that:

Apache-Sybase-CTlib

I vaguely remember I had some problem with the ping method of
Apache-Sybase-CTlib, though. I hope I am wrong.


Jie

> -Pramod
> 
> At 11:47 PM 8/15/00 +, parthasarathy mahendirababu wrote:
> >Hi Pramod,
> >
> >Did u declare, PerlModule as Apache::DBI in the httpd.conf file or 
> >startup.pl in the conf subdirectory on Apache?  This must be declared before 
> >any other Apache modules declared on the configuration file.
> >
> >Mahen.
> >
> >
> >>Hi,
> >>
> >>I'm using Apache::Sybase::CTlib to establish persistent db connectivity in
> >>an effort to move our quite old and extremely dirty scripts from Netscape
> >>onto Apache with mod_perl. I'm establishing this connection on server
> >>startup and I haven't changed anything in my scripts. The above-mentioned
> >>module is supposed to take care of it with no changes.
> >>However, in my error logs, whenever a connection is made to the db, I see
> >>the message : [notice] Establishing connection to :, where
> >>'server' is our db server and 'db' is the database name.
> >>Does this mean that fresh connections are being established on every call
> >>to 'Connect' in my scripts inspite of establishing a connection at server
> >>startup? Does this mean that Apache is not overriding the 'connect' calls
> >>from my scripts?
> >>
> >>Thanks,
> >>Pramod
> 
>

Re: Persistent db connectivity

2000-08-15 Thread Pramod Sokke

I mentioned that I'm using Apache::Sybase::CTlib and not Apache::DBI for
persistent connectivity. Moreover, if the module is not declared and I try
to connect in the startup file, the server won't even start. So that's
obviously taken care of.
My question is more of, how do I know for sure that my server is using the
already opened connection and is not trying to make fresh connections on
every call to 'Connect'? The error logs say : [notice] Establishing
connection to PURCHASEDB:purchasedb.

-Pramod

At 11:47 PM 8/15/00 +, parthasarathy mahendirababu wrote:
>Hi Pramod,
>
>Did u declare, PerlModule as Apache::DBI in the httpd.conf file or 
>startup.pl in the conf subdirectory on Apache?  This must be declared before 
>any other Apache modules declared on the configuration file.
>
>Mahen.
>
>
>>Hi,
>>
>>I'm using Apache::Sybase::CTlib to establish persistent db connectivity in
>>an effort to move our quite old and extremely dirty scripts from Netscape
>>onto Apache with mod_perl. I'm establishing this connection on server
>>startup and I haven't changed anything in my scripts. The above-mentioned
>>module is supposed to take care of it with no changes.
>>However, in my error logs, whenever a connection is made to the db, I see
>>the message : [notice] Establishing connection to :, where
>>'server' is our db server and 'db' is the database name.
>>Does this mean that fresh connections are being established on every call
>>to 'Connect' in my scripts inspite of establishing a connection at server
>>startup? Does this mean that Apache is not overriding the 'connect' calls
>>from my scripts?
>>
>>Thanks,
>>Pramod

Persistent db connectivity

2000-08-15 Thread Pramod Sokke


Hi,

I'm using Apache::Sybase::CTlib to establish persistent db connectivity in
an effort to move our quite old and extremely dirty scripts from Netscape
onto Apache with mod_perl. I'm establishing this connection on server
startup and I haven't changed anything in my scripts. The above-mentioned
module is supposed to take care of it with no changes.
However, in my error logs, whenever a connection is made to the db, I see
the message : [notice] Establishing connection to :, where
'server' is our db server and 'db' is the database name.
Does this mean that fresh connections are being established on every call
to 'Connect' in my scripts inspite of establishing a connection at server
startup? Does this mean that Apache is not overriding the 'connect' calls
from my scripts?

Thanks,
Pramod

Re: [OT] mod_proxy tuning info?

2000-08-15 Thread ___cliff rayman___


have u read this yet?
http://perl.apache.org/guide/scenario.html#mod_proxy

Edward Moon wrote:

> I'm looking for docs or white papers on tuning apache/mod_proxy for
> optimum performance when acting as a reverse proxy for a web farm.
>
> Can anyone point me to a URL or a book that's a good reference?
>
> Thanks,

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

[OT] mod_proxy tuning info?

2000-08-15 Thread Edward Moon


I'm looking for docs or white papers on tuning apache/mod_proxy for
optimum performance when acting as a reverse proxy for a web farm.

Can anyone point me to a URL or a book that's a good reference?

Thanks,

Solaris 2.6, mod_perl 1.24, DBD::Oracle 1.06, Oracle 8.1.6

2000-08-15 Thread Larry Mulcahy

ARGGGHHH.

I'm trying to get the above combination working.

DBD::Oracle was a very tough build. I am afflicted with the 'You must
install a Solaris patch to run this version of the Java runtime' bug.
Using the solution described at
http://x55.deja.com/[ST_rn=ps]/getdoc.xp?AN=611626288&CONTEXT=965926732.856227848&hitnum=37,
I was able to get 'make test' for DBD::Oracle to work.

All seemed well until I started trying to get mod_perl working. I
found I could successfully run a perl script as a CGI application, but
the same script would fail when I tried to run it using mod_perl.
(I've done this before and am aware of the need to use a 'package'
declaration in the CGI application for use with Apache::Registry. The
application I'm testing with previously worked on another mod_perl
server).

The error from the Apache server log looks like:

[Tue Aug 15 11:22:20 2000] [error] Can't load
'/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/auto/DBD/Oracle/Oracle.so' for
module DBD::Oracle: ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error:
file /usr/local/oracle/u01/app/oracle/product/8.1.6/lib/libjox8.so: symbol kzspga_:
referenced symbol not found at /usr/local/lib/perl5/5.6.0/sun4-solaris/DynaLoader.pm
line 200.
at /usr/local/apache/cgi-bin-secure/ipeng-only/ipengdev-query line 13
Compilation failed in require at
/usr/local/apache/cgi-bin-secure/ipeng-only/ipengdev-query line 13.
BEGIN failed--compilation aborted at
/usr/local/apache/cgi-bin-secure/ipeng-only/ipengdev-query line 13.

I spent some time building an awful looking command to link Oracle.so
with all the undefined externals resolved. But when I finally got
that, the 'You must install a Solaris patch to run this version of the
Java runtime' message came back.

I've tried going back to DBD::Oracle 1.03 and using the '-nob' option
of DBD::Oracle's Makefile.PL. This didn't help.

Counting the time I spent just getting DBD::Oracle built, I'm into
this for 3 or 4 days. I've done the same thing in Linux numerous
times, but not in Solaris, and not with Oracle 8.1.6 (highest release
I used previously was 8.0.5).

At one point I succeeded in building DBD::Oracle using an older Oracle
version (8.1.5, before using the method described in the deja.com URL
above), but when I deleted the older Oracle version, it broke
DBD::Oracle... attempts to use DBD::Oracle were referring to
nonexistent files in the 8.1.5 directory tree. I never got around to
trying mod_perl with DBD::Oracle built this way.

I've looked through the README.java that comes with DBD::Oracle 1.06.
Setting LD_PRELOAD only seems to get me segfaults:

# LD_PRELOAD=/lib/libthread.so.1; export LD_PRELOAD
# make test
make: *** [test] Segmentation Fault (core dumped)

Anyone have a suggestion? I guess my next step will be to attempt
'perform surgery on the Oracle installation'.

For background, there's some discussion of this problem (I think it's
the same problem) at:

http://www.egroups.com/message/modperl/26552
http://www.egroups.com/message/modperl/26701
http://marc.theaimsgroup.com/?l=perl-dbi&m=95935887014413&w=2

--
Larry Mulcahy [EMAIL PROTECTED]
PGP public key at:
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x2C4C5A03

Re: Session manager(s)-how to set an outbound session ?

2000-08-15 Thread Bill Moseley

At 11:24 PM 08/14/00 +, Greg Cope wrote:

>I'm writing a Session-Manager (transhandler) i.e deals with getting a
>session id from cookies, uri, or query args, and sets one and redirects
>if neccessary.  This is meant to compliment Apache::Session - in that
>you use Apache::Session to store your session data.

FWIW -- I'm using a modified version of Ken Williams' Apache::AuthCookie to
handle session control via cookies or munged URLs.  I originally wanted to
use his custom login script instead of the pop-up browser login, but I had
clients that don't have cookies enabled.  So I added the URL munge into
AuthCookie.

I realized that bypassing the Apache::AuthCookie login script that
AuthCookie was perfect (at least for my needs) for simple session
management.  

The only changes needed to the AuthCookie config are:

# Enable URL munging
PerlTransHandler  Sample::AuthCookie

# Disable the login script requirement
PerlSetVar WhatEverLoginScript NONE

If anyone is interested, please let me know.  (Ken, are these features
worth adding to AuthCookie?)

BTW -- Why can't I use 

PerlTransHandler  Sample::AuthCookieHandler

instead of

PerlTransHandler  Sample::AuthCookie

Shouldn't handler() be found in @ISA?

Bill Moseley
mailto:[EMAIL PROTECTED]

Seg fault with mod_perl and mysql

2000-08-15 Thread Mike Szydlo


Hello all,

I'm new to mysql, like it, but I and have experienced seg faults using
DBI->connect() under mod_perl registry.
My script runs fine under straight CGI.

I have found some reference to this on-line, but no solution.

For example,

http://www.mail-archive.com/modperl@apache.org/msg04900.html


More precisely, The error message I got was: 

[Sun Aug 13 14:27:01 2000] [notice] child pid 390 exit signal
Segmentation fault (11) 

This appeared in my apache error log.

It ocurred right after a perl DBI->connect() statement!

I am using suse linux 6.1, 
the mysql perl DBD driver Msql-Mysql-modules-1.2209/lib/DBD/mysql
and the mysql binary release  /mysql-3.22.32-pc-linux-gnu-i686/

Do you have any idea which piece is causing the problem? And how to
patch it?

As I mentioned, I did some searching on line and I think some other
developers have had this too!

Thanks you 

Mike Szydlo

Los Angeles, CA - Software Developer

2000-08-15 Thread Erica Scott


My client, a professional services company that integrates the building and
marketing of digital businesses, is backed by one of the largest
Interactive, Public Relations, and Advertising groups in the world.  They
are ranked by Adweek as one of the top 20 largest Interactive Services
companies in the world.  They have an initial base of nearly 500 employees
serving clients in 12 offices and 5 countries.  

Located in West Hollywood, this client services both B2C and B2B clients,
with strong industry expertise in categories that include consumer goods,
retailing, financial services, technology and Internet, telecommunications,
and media and entertainment.  Their clients include many Fortune 100
companies as well as a range of dot-com enterprises.  The culture is hip,
energetic, eclectic, and creative.  

You will be responsible for developing and maintaining e-commerce sites for
major national brands.  Significant learning opportunity!  The successful
candidate will be trained on the following:  MS Site Server, IBM Net
Commerce, Interworld, Web Sphere, Vignette Story Server, Broadvision, and
possible certification in Java.

Principle responsibilities include:
*   Engineer assigned projects according to project specifications.
*   Assist Senior Developers in the Research and Development of new
products and technologies.
*   Quality assuring sites and changes to sites on all browsers and
platforms.
*   Communicating effectively with Designers and Producers when
gathering information and files to build web sites.

The successful candidate MUST have:
*   At least 2 years of experience in designing, developing, and
implementing web applications using Perl/mod_perl, ASP and SQL.
*   Knowledge of one or all of the following databases:  SQL Server,
DB2, and/or Oracle.
*   Familiarity with one or all of the following e-commerce packages:
Net Commerce, Site Server, InterWorld, etc.

You must possess a willingness and enthusiasm for learning and working with
others.  Additionally, you will have exceptional problem solving skills
coupled with creative and logical thinking.

Bachelor's degree in Computer Science preferred.  

Benefits include employer-paid medical, dental, and vision; 401k; Quarterly
Profit Sharing; Tuition assistance; and opportunities to learn new languages
and technologies.  

Interested candidates please forward a copy of your resume, desired annual
salary, and a daytime contact number.
 
Regards,
Erica Scott
Technical Recruiter
Comforce Technical Services
[EMAIL PROTECTED]  
Tel:  (800) 660-9544 x124 
Pager:  (949) 657-0403
www.comforce.com

Re: Looking for info/docs

2000-08-15 Thread ___cliff rayman___

Derek Simkowiak wrote:

> 2) One webpage I've read says that mod_perl "compiles" (interprets) each
> Perl script only once, and then retains the compiled code in memory.  Is
> that something that was custom-made for mod_perl, or is that a feature of
> using an embedded Perl interpreter?  Can you point me to a file/line of code
> in mod_perl?
>

a feature of an embedded perl interpreter.  the application that loads the
interpreter stays running.  and in less it explicitly closes the interpreter, it
stays running.  unless the perl script is reloaded for some reason, the compiled
code stays resident in the interpreter, which is resident in the embedding
application.

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

Re: Apache::Upload buffering issues?

2000-08-15 Thread ___cliff rayman___


Ian Mahuron wrote:

> What is the proper way to take the filehandle provided by $upload->fh and write the 
>file to disk?  I seem to be having buffering
> issues w/ the following (file is truncated):
>
> if (open(OUTFILE, ">$u_fullpath")) {
> print OUTFILE $buffer while read($fh, $buffer, 8*1024);
> } else {
> ...
> }
>
> a simple $| = 1; before the print didn't seem to help.. maybe OUTFILE is not hot?

select((select(OUTFILE), $|++)[0]);  #unbuffer OUTFILE and return select to prev state

> Dunno.. this is my first run in w/ buffering
> issues.  I hope someone can help.

i see u are not checking for errors on open. u should.
u should also check for errors on close.  if u get an error on close, then the file 
you are closing is probably not going to be
written with all data.

>
>
> TIA
>
> Ian

hth,

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

Looking for info/docs

2000-08-15 Thread Derek Simkowiak



 Hello,
I need to write a (new) Apache module that uses embedded Perl in a
high-load server environment.

While this is not directly related to the use of mod_perl, I have
many questions which the mod_perl team can probably answer.  In particular, 

1) Are there any issues related to using an embedded Perl interpreter in a
threaded server  application?  In particular, I'd like each thread to be
able to interpret its own Perl scripts, without the performance penalty of
creating a new interpreter; is that possible?

2) One webpage I've read says that mod_perl "compiles" (interprets) each
Perl script only once, and then retains the compiled code in memory.  Is
that something that was custom-made for mod_perl, or is that a feature of
using an embedded Perl interpreter?  Can you point me to a file/line of code
in mod_perl?

I'm looking to understand embedding Perl.  If you can refer me to
any documents other than perlembed and perlguts, I would greatly appreciate
it.


Thank You,
Derek Simkowiak
[EMAIL PROTECTED]

Re: Apache::Upload buffering issues?

2000-08-15 Thread Ken Y. Clark


On Tue, 15 Aug 2000, Ian Mahuron wrote:

> What is the proper way to take the filehandle provided by $upload->fh and write the 
>file to disk?  I seem to be having buffering
> issues w/ the following (file is truncated):
> 
> if (open(OUTFILE, ">$u_fullpath")) {
>   print OUTFILE $buffer while read($fh, $buffer, 8*1024);
> } else {
>   ...
> }
> 
> a simple $| = 1; before the print didn't seem to help.. maybe OUTFILE is not hot?  
>Dunno.. this is my first run in w/ buffering
> issues.  I hope someone can help.
> 
> TIA
> 
> Ian
> 
> 

here's what i do in one of my modules:

my $file_size = $upload->size || 0;
if ($file_size == 0) {
return $self->err_out("You didn't supply a valid file.");
}

#
# write the data to file, making sure what gets
# written is the same as what we expected
#
my $umask = umask 02;
eval {
no strict 'refs';
my $fh = $upload->fh or die 'No file handle';
my $data   = '';
my $length = 0;
{
local *F;
open(F, "> $file_path") or die "Failed to open '$file_path': $!";
while ( read($fh, $data, 4096) ) {
print F $data;
$length += length($data);
}
close F;
}
if ($length != $file_size) {
die "Failed to write '$file_path' to file";
}
};

#
# reset umask
#
umask $umask;

hth,

ky

Apache::Upload buffering issues?

2000-08-15 Thread Ian Mahuron


What is the proper way to take the filehandle provided by $upload->fh and write the 
file to disk?  I seem to be having buffering
issues w/ the following (file is truncated):

if (open(OUTFILE, ">$u_fullpath")) {
print OUTFILE $buffer while read($fh, $buffer, 8*1024);
} else {
...
}

a simple $| = 1; before the print didn't seem to help.. maybe OUTFILE is not hot?  
Dunno.. this is my first run in w/ buffering
issues.  I hope someone can help.

TIA

Ian

RE: Question about $sth->finish;

2000-08-15 Thread Jay Jacobs

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."

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.

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

Jay Jacobs

RE: Question about $sth->finish;

2000-08-15 Thread Tom Mornini


On Tue, 15 Aug 2000, Vladislav Safronov wrote:

> Ok. I think, the answers clear the problem, but I have yet more question.
> 
> What can you say about this code? is it ok (overwriting previous handle)?
> 
> ==
> sub foo {
>   my $dbh = shift;
> 
>   my $sql1 = "select *...
>   my $sql2 = "select *...
> 
>   my $sth = $dbh->prepare($sql1);
>   $sth->execute;
>   .. fetch some data.
> 
>   # should be $sth->finish inserted??
> 
>   $sth = $dbh->prepare($sql2); # we overwrite previous handle saved in $sth
> ..
>   $sth->execute;
>   .. fetch some data.
>   return;
> }

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.

-- 
-- Tom Mornini
-- InfoMania Printing and Prepress

RE: Question about $sth->finish;

2000-08-15 Thread Michael Peppler


Matt Sergeant writes:
 > On Tue, 15 Aug 2000, Michael Peppler wrote:
 > 
 > > Matt Sergeant writes:
 > >  > On Tue, 15 Aug 2000, Vladislav Safronov wrote:
 > >  > 
 > >  > > Ok. I think, the answers clear the problem, but I have yet more question.
 > >  > > 
 > >  > > What can you say about this code? is it ok (overwriting previous handle)?
 > >  > 
 > >  > [snip]
 > >  > 
 > >  > Well it depends on the DBMS. For example Sybase might not like it if you
 > >  > haven't read everything from the $sth first - it will bite you in the bum
 > >  > with locks. Others will be fine. So just be careful...
 > > 
 > > Actually what happens with Sybase is this:
 > > 
 > > If $sth has pending results when prepare() is called DBD::Sybase opens 
 > > a new connection (because it sees that the $dbh already has an active
 > > $sth). When the return value from prepare() is assigned to $sth the
 > > DESTROY method for the old $sth is called, which cancels the previous
 > > query. 
 > > 
 > > So I think that you *should* be safe from deadlocks, but the problem
 > > will be getting additional connections created, which is not really
 > > optimal. 
 > 
 > Isn't there something different happening when AutoCommit = 0 though?

If AutoCommit = 0 then you'll get a fatal error because DBD::Sybase
can't guarantee consistent rollback behavior accross multiple
connections (which is what happens in this case, even though the first 
$sth gets destroyed before the second one gets executed).

Michael
-- 
Michael Peppler -||-  Data Migrations Inc.
[EMAIL PROTECTED]-||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]

RE: Question about $sth->finish;


On Tue, 15 Aug 2000, Michael Peppler wrote:

> Matt Sergeant writes:
>  > On Tue, 15 Aug 2000, Vladislav Safronov wrote:
>  > 
>  > > Ok. I think, the answers clear the problem, but I have yet more question.
>  > > 
>  > > What can you say about this code? is it ok (overwriting previous handle)?
>  > 
>  > [snip]
>  > 
>  > Well it depends on the DBMS. For example Sybase might not like it if you
>  > haven't read everything from the $sth first - it will bite you in the bum
>  > with locks. Others will be fine. So just be careful...
> 
> Actually what happens with Sybase is this:
> 
> If $sth has pending results when prepare() is called DBD::Sybase opens 
> a new connection (because it sees that the $dbh already has an active
> $sth). When the return value from prepare() is assigned to $sth the
> DESTROY method for the old $sth is called, which cancels the previous
> query. 
> 
> So I think that you *should* be safe from deadlocks, but the problem
> will be getting additional connections created, which is not really
> optimal. 

Isn't there something different happening when AutoCommit = 0 though?

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

RE: Question about $sth->finish;

2000-08-15 Thread Michael Peppler

Matt Sergeant writes:
 > On Tue, 15 Aug 2000, Vladislav Safronov wrote:
 > 
 > > Ok. I think, the answers clear the problem, but I have yet more question.
 > > 
 > > What can you say about this code? is it ok (overwriting previous handle)?
 > 
 > [snip]
 > 
 > Well it depends on the DBMS. For example Sybase might not like it if you
 > haven't read everything from the $sth first - it will bite you in the bum
 > with locks. Others will be fine. So just be careful...

Actually what happens with Sybase is this:

If $sth has pending results when prepare() is called DBD::Sybase opens 
a new connection (because it sees that the $dbh already has an active
$sth). When the return value from prepare() is assigned to $sth the
DESTROY method for the old $sth is called, which cancels the previous
query. 

So I think that you *should* be safe from deadlocks, but the problem
will be getting additional connections created, which is not really
optimal. 

Michael
-- 
Michael Peppler -||-  Data Migrations Inc.
[EMAIL PROTECTED]-||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]

Re: Question about $sth->finish;

On Tue, 15 Aug 2000, Keith G. Murphy wrote:

> (Boggle)  Really? 'My' variables going out of scope don't always get
> freed up?  Or is this strictly an object thing with DESTROY?

Well why would you care if my $str = "hello world" didn't get freed via
this bug? It only matters for objects that do something in DESTROY...

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

Re: Question about $sth->finish;

2000-08-15 Thread Keith G. Murphy


Matt Sergeant wrote:
> 
> On Tue, 15 Aug 2000, 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? Wouldn't it be automaticly called
> > when
> > sub foo ends (when my variable $sth get destroyed)?
> 
> $sth doesn't always get destroyed when foo ends (due to a bug in all
> perls).

(Boggle)  Really? 'My' variables going out of scope don't always get
freed up?  Or is this strictly an object thing with DESTROY?

RE: Question about $sth->finish;

On Tue, 15 Aug 2000, Vladislav Safronov wrote:

> Ok. I think, the answers clear the problem, but I have yet more question.
> 
> What can you say about this code? is it ok (overwriting previous handle)?

[snip]

Well it depends on the DBMS. For example Sybase might not like it if you
haven't read everything from the $sth first - it will bite you in the bum
with locks. Others will be fine. So just be careful...

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

RE: env in background process

2000-08-15 Thread Niraj Sheth


Follow up on this.

script1.pl(set FOO1 env)
===
#!/usr/local/bin/perl

print "Content-type: text/html\n\n";
print "PID = $$\n";
print "SCRIPT1 with FOO1\n";

#local %ENV = %ENV;

$ENV{FOO1} = "foo1";
print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;

$command = "dump_env";
print `$command &`; # put it in the background

-- end

script2.pl(set FOO2 env)
===
#!/usr/local/bin/perl

print "Content-type: text/html\n\n";
print "PID = $$\n";
print "SCRIPT1 with FOO2\n";

#local %ENV = %ENV;

$ENV{FOO2} = "foo2";
print map { "$_ = $ENV{$_}\n"; } sort keys %ENV;

$command = "dump_env";
print `$command &`; # put it in the background

-- end

dump_env
===
#!/usr/local/bin/perl

print "$0 @ARGV\n";

print map { "$0 $_ = $ENV{$_}\n"; } sort keys %ENV;

--end

running "httpd -X" i will get FOO1 and FOO2 both from the print
statement of dum_env.
while script1.pl is ONLY printing FOO1 which is correct as well as
script2.pl is ONLY printing FOO2 which is also correct.

so why dump_env is getting both?
If I either uncomment "local %ENV = %ENV;" in script or put "%ENV = ();"
in PerlCleanupHandler then dump_env is working fine.
I tried both Apache::PerlRun and Apache::Registry which same result.

I would appreciate any help.

-Niraj

> -Original Message-
> From: Niraj Sheth [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 14, 2000 12:10 PM
> To: [EMAIL PROTECTED]
> Subject: env in background process
>
>
> Hi,
>
> I am having very strange problem with environment variables.
>
> >From Apache::PerlRun script(cgi) I am setting env and firing
> background
> process ..
> system("$command &") (or print `$command &`;)
>
> now looks like environment variable being persistence b/w different
> requests ONLY in background process. so it's looks to me that mod_perl

> is setting proper "Perl Level" env but failing to reset env
> at "c level"
> or "process level". I know it's sounds very weird.
> /perl-status?env is printing correctly but my background process
> ($command) is printing few extra env, which i set it in different cgi
> script.
>
> e.g. "script1.pl" is setting $ENV{foo1} = "foo1" and firing print
> `command1 &`;
> and "script2.pl" is setting $ENV{foo2} = "foo2" and firing print
> `command2 &`;
>
> after few hits both env(foo1 and foo2) are visible to both background
> processes.
> while /perl-status?env is displaying correctly.
> Here command1 and command2(perl scripts) are just printing env
>
> Apache/1.3.9 (Unix) mod_perl/1.21
> Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
>   Platform:
> osname=solaris, osvers=2.6, archname=sun4-solaris
> uname='sunos nlsun268 5.6 generic_105181-14 sun4u sparc
> sunw,ultra-4
> '
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef useperlio=undef d_sfio=undef
>   Compiler:
> cc='gcc', optimize='-O', gccversion=2.8.1
> cppflags='-I/usr/local/include'
> ccflags ='-I/usr/local/include'
> stdchar='unsigned char', d_stdstdio=define, usevfork=false
> intsize=4, longsize=4, ptrsize=4, doublesize=8
> d_longlong=define, longlongsize=8, d_longdbl=define,
> longdblsize=16
> alignbytes=8, usemymalloc=y, prototype=define
>   Linker and Libraries:
> ld='gcc', ldflags =' -L/usr/local/lib'
> libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
> libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
> libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
>   Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
>
>
> Any comments?
>
> Thanks,
> Niraj
>

RE: Question about $sth->finish;

2000-08-15 Thread Vladislav Safronov


Ok. I think, the answers clear the problem, but I have yet more question.

What can you say about this code? is it ok (overwriting previous handle)?

==
sub foo {
my $dbh = shift;

my $sql1 = "select *...
my $sql2 = "select *...

my $sth = $dbh->prepare($sql1);
$sth->execute;
.. fetch some data.

# should be $sth->finish inserted??

$sth = $dbh->prepare($sql2); # we overwrite previous handle saved in $sth
..
$sth->execute;
.. fetch some data.
return;
}
==

Vlad.

Tainted @INC

2000-08-15 Thread Dave Jenkins


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: Question about $sth->finish;

2000-08-15 Thread David Mitchell


Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> This can be demonstrated with a very simple object class with a DESTROY
> method. There's a message somewhere in the p5p archives about this from
> me.

That's

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg00604.html

to save anyone else having to look :-)

RE: Question about $sth->finish;

On Tue, 15 Aug 2000, Vladislav Safronov wrote:

> "my" (perl's my) variables doesn't always get destoyed, does it Perl's 
> documentation say that "my" vars are the most safe since they get destroyed
> when they get out of scope ...

I said this was a bug in Perl, although I don't think that 5.6.1 is fixing
it (due out "soon"), because its quite hard to track down. It occurs in
conditionals:

if (my $rec = foo()) {
# lexicals in foo() not destroyed here
}
# lexicals in foo() destroyed here.

This can be demonstrated with a very simple object class with a DESTROY
method. There's a message somewhere in the p5p archives about this from
me.

(and I don't mean the lexicals that might get returned and assigned to
$rec, for anyone assuming I don't know what I'm talking about)...

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

RE: Question about $sth->finish;

2000-08-15 Thread Vladislav Safronov


> On Tue, 15 Aug 2000, 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? Wouldn't it be 
> automaticly called
> > when
> > sub foo ends (when my variable $sth get destroyed)?
> 
> $sth doesn't always get destroyed when foo ends (due to a bug in all
> perls). But otherwise, yes.

"my" (perl's my) variables doesn't always get destoyed, does it Perl's 
documentation say that "my" vars are the most safe since they get destroyed
when they get out of scope ...

Vlad.

RE: Bug in Apache::ASP XMLSubs when an argument includes '>'-characte rs?


On Tue, 15 Aug 2000, Henrik Tougaard wrote:

> > XML attributes can't contain "<" or "&" characters, or the 
> > same quote that
> > they are surrounded by. The following are the encodings you can use
> > (and XMLSubsMatch needs to unravel):
> > 
> > <   =>  "<"
> > >   =>  ">"
> > &   =>  "&"
> > "   =>  """
> > '   =>  "'"
> > 
> > Note that only "<" is needed for your example (since encoding the
> > ">" isn't mandatory in XML generally).
> > 
> Well this does limit the usefullness of the XMLSubs feature.
> I had hoped that it would be possbile to use any perl expression in
> the attributes - as an easy way of giving arguments to the perl-sub.

Note that I'm speaking not from Apache::ASP's point of view, but from an
XML point of view. I don't know if Joshua wants to work around these rules
- I certainly never saw a necessity of encoding "<" in an attribute
value. Its not like its really difficult to parse without it. In fact its
_more_ overhead to do it the way the XML spec specifies...

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

RE: Bug in Apache::ASP XMLSubs when an argument includes '>'-characte rs?


> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> On Fri, 11 Aug 2000, Henrik Tougaard wrote:
> > With this simple .asp page I get an error:
> > 
> >  
> > [My XMLSubMatch is set to Fiks:\w+  - the name of the 
> subroutine doesn't
> > matter]
> > 
> > It seems as if the '>' in the '' argument confuses the parser.
> 
> [snip]
> 
> > Is this a (mis)feature or a parser bug?
> 
> parser bug - it should have died earlier at the < sign :-)
> 
> XML attributes can't contain "<" or "&" characters, or the 
> same quote that
> they are surrounded by. The following are the encodings you can use
> (and XMLSubsMatch needs to unravel):
> 
> <   =>  "<"
> >   =>  ">"
> &   =>  "&"
> "   =>  """
> '   =>  "'"
> 
> Note that only "<" is needed for your example (since encoding the
> ">" isn't mandatory in XML generally).
> 
Well this does limit the usefullness of the XMLSubs feature.
I had hoped that it would be possbile to use any perl expression in
the attributes - as an easy way of giving arguments to the perl-sub.

Pity

--
Henrik

RE: Question about $sth->finish;


>From: Vladislav Safronov [mailto:[EMAIL PROTECTED]]
> sub foo {
>   my $dbh = shift;
> 
>   my $sql = ...
> 
>   my $sth = $dbh->prepare($sql);
>   $sth->execute;
>   $sth->finish;
> }
> ===
> Do I always need to call $sth->finish? Wouldn't it be 
> automaticly called when
> sub foo ends (when my variable $sth get destroyed)?

You do *NOT* need to call $sth->finish - never, never, never.
[OK. not quite true: you need to call $sth->finish when you end a
 select statement before reading the last data in the cursor and
 want to reexecute the select statement. So the answer is:
  NEVER!!!]

If you worry about the statement handle still being defined I
would reccomend using  C instead. That will
certainly release all resources owned by the statement.
$sth->finish is just for very special cases - and this is
not one of them.

--
Henrik Tougaard, [EMAIL PROTECTED]

Re: Question about $sth->finish;