persistentperl-users — User and development discussion

[Persistentperl-users] Re: [Speedycgi-users] Help with STDOUT

[Sam H. <sa...@da...>]

Your script is trying to read input from STDOUT, is that correct?  That
won't work - STDOUT works only for output, not input.

This might work, if and when I add code to pass filehandles, but at the
moment, PersistentPerl won't do that.


 > I have a problem grabbing STDOUT with PersistentPerl.  It works fine when called via /usr/bin/perl or /usr/bin/suidperl.  The script, and the debug output is below.   
 > 
 > perl and suidperl both have a line of STDOUT.  perperl does not.  WTF.
 > 
 > Thanks for any advice!
 > 
 > --------------
 > 
 > #!/usr/bin/suidperl -w
 > #!/usr/bin/perl -w 
 > #!/usr/bin/perperl -w -- -M20 -r5
 > # START TEST, RUN 3 TIMES USING DIFFERENT INTERPRETERS LISTED ABOVE
 > 
 >  select(STDIN); $|=1;
 > 
 >  while (<STDIN>) {
 >    chomp($_);
 >    &debug("STDIN LINE: $_");
 >  }
 >  close(STDIN);
 > 
 >  select(STDOUT); $|=1;
 >  open(SOUT,"<&STDOUT");
 >  while (<SOUT>) {
 >    &debug("SOUT LINE: $_");
 >  }
 > 
 > exit;
 > 
 > ##############################
 > 
 > sub debug {
 > 
 >  my $log = shift;
 > 
 >   open (T,">>/tmp/debug.log");
 >   flock(T,2);
 >   print T $log . "\n";
 >   close (T);
 > }
 > 
 > ##############################
 > # EOF
 > 
 > 
 > DEBUG OUTPUT UNDER PERPERL
 > ----------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:40:22 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:40:21 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN:
 > 
 > 
 > DEBUG OUTPUT UNDER PERL
 > ------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:42:08 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:42:07 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN: 
 > SOUT LINE: Fda...@nm...Tda...@nm... 
 > 
 > 
 > DEBUG OUTPUT UNDER SUIDPERL
 > --------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:43:06 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:43:06 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN: 
 > SOUT LINE: Fda...@nm...Tda...@nm...
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by:Crypto Challenge is now open! 
 > Get cracking and register here for some mind boggling fun and 
 > the chance of winning an Apple iPod:
 > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
 > _______________________________________________

[Persistentperl-users] Followup to my STDOUT issue

[Dallas E. <da...@nm...>]

I was reading the docs on how speedy works, and seen

When executed, the speedy frontend does the following:
   1. Looks for an available backend to run this script.
   2. If no backends are available, starts a new one.
   3. As soon as a backend is located, connects to it and starts to send =
over %ENV, @ARGV and the STDIN data.
   4. Brings back the STDOUT and STDERR data from the backend and sends =
it to its output.=20

The speedy backend does the following:
   1. Initializes the perl interpreter and compiles the perl script
   2. Waits for a frontend to contact it
   3. Once a frontend contacts it, reads in and initializes %ENV and =
@ARGV
   4. Sets up STDIN, STDOUT and STDERR so that they are connected to the =
frontend via Unix sockets.
   5. Executes the perl code.
   6. Goes back and waits for another frontend to contact it.=20


When I look at Step 3 on how speedy works, I see that it does not pipe =
STDOUT to the backend?  How am I supposed to read STDOUT from a previous =
pipe into my script??  Like the one I posted before.  I'm trying to =
write a filter that mail pipes through, but I dont want to invoke a perl =
interpreter for each email!   In order to get the envelope addresses, I =
have to read STDOUT from the qmail-smtpd pipe to my script.

Is this impossible with perperl or should I maybe look into fastcgi?

Thanks.
Dallas

[Persistentperl-users] Help with STDOUT

[Dallas E. <da...@nm...>]

I have a problem grabbing STDOUT with PersistentPerl.  It works fine =
when called via /usr/bin/perl or /usr/bin/suidperl.  The script, and the =
debug output is below.  =20

perl and suidperl both have a line of STDOUT.  perperl does not.  WTF.

Thanks for any advice!

--------------

#!/usr/bin/suidperl -w
#!/usr/bin/perl -w=20
#!/usr/bin/perperl -w -- -M20 -r5
# START TEST, RUN 3 TIMES USING DIFFERENT INTERPRETERS LISTED ABOVE

 select(STDIN); $|=3D1;

 while (<STDIN>) {
   chomp($_);
   &debug("STDIN LINE: $_");
 }
 close(STDIN);

 select(STDOUT); $|=3D1;
 open(SOUT,"<&STDOUT");
 while (<SOUT>) {
   &debug("SOUT LINE: $_");
 }

exit;

##############################

sub debug {

 my $log =3D shift;

  open (T,">>/tmp/debug.log");
  flock(T,2);
  print T $log . "\n";
  close (T);
}

##############################
# EOF


DEBUG OUTPUT UNDER PERPERL
----------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:40:22 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:40:21 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:


DEBUG OUTPUT UNDER PERL
------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:42:08 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:42:07 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:=20
SOUT LINE: Fda...@nm...Tda...@nm...=20


DEBUG OUTPUT UNDER SUIDPERL
--------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:43:06 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:43:06 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:=20
SOUT LINE: Fda...@nm...Tda...@nm...

[Persistentperl-users] exit, fork, & signal handlers w/ Persistent Perl

[Kevin <ke...@bl...>]

Hi all,

	When coding or porting a program to play nicely with Persistent Perl (aka SpeedyCGI), is there anything special that needs to be done when one uses exit, fork, or a signal handler?  FastCGI and mod_perl seem to require you to do special things so the programs work correctly, but the webpage for Persistent Perl doesn't really mention anything special.

	Thanks,
	Kevin

Re: [Persistentperl-users] Problem with getting PersistentPerl 2.21 working on HP/UX using GCC

[<Jes...@va...>]

>    Martin Houston <mho...@de...>
>    20.02.2003 10:45
>    Please respond to mhouston
>
>Are you using the HP Ansi C compiler (cc) to build PersistentPerl - and
does
>it pass 'make test' for you with the linker flags reinstated?

I'm using the default 'cc', which I assume is what you mean..

I just tried using aCC, which we also have, but that produces a lot of
errors when doing 'make':

aCC -c -I../src -I. -D_HPUX_SOURCE -I/usr/local/include +DAportable
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae -O   -DVERSION=\"2.21\"
-DXS_VERSION=\"2.21\" +z
-I/usr/local/packages/perl-5.6.1/lib/5.6.1/PA-RISC2.0/CORE
-DPERPERL_PROGNAME=\"perperl_backend\" -DPERPERL_VERSION=\"2.21\"
-DPERPERL_BACKEND perperl_perl.c
aCC: warning 901: unknown option: `-Ae': use +help for online
documentation.
Error 212: "perperl_perl.c", line 397 # Argument type 'void *' does not
match
    expected parameter type 'sv *'.
            my_call_sv(get_perlvar(&PERLVAR_RUN_SHUTDOWN));
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error 212: "perperl_perl.c", line 544 # Argument type 'void *' does not
match
    expected parameter type 'const char *'.
            sv_catpvn(sv, mi->addr, mi->maplen);
                          ^^^^^^^^

etc. pp.

No, make test still doesnt work after the change (tho I can now get rid of
my 'crt0.o' patch in the HP-UX version..)

Maybe I'm just missing some permissions or something? Like I said, it seems
to start the backend, but somehow cant connect to it? (Im just a normal
user, not root ,)

While running make test, ps -aef | grep -i perl says this:
     jer 16386 16385  0 11:18:53 pts/tc    0:00 /usr/local/new/bin/perl
-I../blib/arch -I../blib/lib -I/usr/
     jer 16436 16294  1 11:19:18 pts/td    0:00 grep -i perl
     jer 16428 16410  0 11:19:15 pts/tc    0:00 sh -c
/home/mis/jer/perl/src/PersistentPerl-2.21/perperl/per
     jer 16378 16377  0 11:18:53 pts/tc    0:00 make test LIB=
LIBPERL_A=libperl.a LINKTYPE= PREFIX=/home/mi
     jer 16377 16331  0 11:18:53 pts/tc    0:00 /bin/sh -c cd perperl &&
test -f Makefile && make test LIB="
     jer 16385 16378  0 11:18:53 pts/tc    0:00 /bin/sh -c
PERL_DL_NONLAZY=1 PERPERL=/home/mis/jer/perl/src/
     jer 16429 16428  0 11:19:15 pts/tc    0:00
/home/mis/jer/perl/src/PersistentPerl-2.21/perperl/perperl t
     jer 16431     1 100 11:19:15 ?         0:01
/home/mis/jer/perl/src/PersistentPerl-2.21/perperl_backend/p
     jer 16410 16386  0 11:19:07 pts/tc    0:00 /usr/local/new/bin/perl -w
t/argv.t


>ALso what perl version are you linking against (just do a perl -v command
on
>the perl that you did perl Makefile.PL with.)
>

jer@volvo: ~ > perl -v

This is perl, v5.6.1 built for PA-RISC2.0

Copyright 1987-2001, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.


Any other ideas? *sigh*

--
Martin Houston            Linux Consultant
mho...@de...      Phone: 07970 850961

Re: [Persistentperl-users] Problem with getting PersistentPerl 2.21 working on HP/UX using GCC

[Martin H. <mho...@de...>]

On Thursday 20 February 2003 09:18, Jes...@va... wrote:
> Hi Martin,
>
> Just out of interest, did you also build your Perl using that gcc ? (It's
> been mentioned a few times in the archives..)

I built a Perl 5.8.0 using the GCC 3.2 pre release depot file  dowloaded from 
HP.

Perl passes all regression tests so I am reasonably confident that it has been 
built correctly.
>
> Since perl is already installed on my HP-UX boxes I have no idea what they
> were compiled with, and cant/dont want to compile my own perl (this is a
> project in which the result will be installed on customer machines, and I
> dont want them to have to do that..)

Are you using the HP Ansi C compiler (cc) to build PersistentPerl - and does  
it pass 'make test' for you with the linker flags reinstated?

ALso what perl version are you linking against (just do a perl -v command on 
the perl that you did perl Makefile.PL with.)

-- 
Martin Houston				Linux Consultant
mho...@de...		Phone: 07970 850961

Re: [Persistentperl-users] Problem with getting PersistentPerl 2.21 working on HP/UX using GCC

[<Jes...@va...>]

Hi Martin,

Just out of interest, did you also build your Perl using that gcc ? (It's
been mentioned a few times in the archives..)

Since perl is already installed on my HP-UX boxes I have no idea what they
were compiled with, and cant/dont want to compile my own perl (this is a
project in which the result will be installed on customer machines, and I
dont want them to have to do that..)

And well done for finding the source of the errant LD parameters.. I tried
and gave up :)

Jess

[Persistentperl-users] Problem with getting PersistentPerl 2.21 working on HP/UX using GCC

[Martin H. <mho...@de...>]

I am trying to build PersistenPerl 2.21 against perl 5.8.0 on a HP/UX 11.0 
machine (PARISC 1.1  CPU).

The C compiler I am using is gcc version 3.2 for PARISC (32 bit version).

At first I had the same problem as Jess with the '-Wl,-E' linker options. 
However I solved this not by deleting them but by tracking down in 
src/PersistentMake.pl line 337    

$remove_libs \$(LD) -o ${my_name_val} \$(OBJECT) $ldopts

I made into

$remove_libs \$(CC) -o ${my_name_val} \$(OBJECT) $ldopts

As the C compiler knows to strip the '-Wl' off the front of the argument 
before passing the -E to the linker.

This one tweak means that PersistentPerl builds and links. However I get semi 
random failures in the test suite.


I have already raised a bug in sourceforge about this - see 
http://sourceforge.net/tracker/index.php?func=detail&aid=681085&group_id=62848&atid=502016

In short I get "temp file corrupt" messages and some of the tests fail, but 
not the same ones each time, which leads me to believe the problem is 
something more deep rooted than what the tests are testing for.

Has anyone managed to get PersistentPerl working using the HP Ansi C compiler? 
I would like to know if the problem I am seeing is just because I am using 
GCC rather than the 'official' (but expensive) compiler.

-- 
Martin Houston				Linux Consultant
mho...@de...		Phone: 07970 850961

Re: [Persistentperl-users] speedy/perperl on virtual host probs.

[Lorenzo D. <Lor...@fl...>]

Hi again,

Damn, it hurts to be so dumb! If this list is still alive, pls forget my 
earlier email. I have commited stupidy beyond words. I downloaded/decided to 
try kmon (something like a kde front end for mon), and, overeager as always, 
I wanted to give it a test run. I attacked it with loads of tests, including 
httpd on localhost. AARGH! My session handler will create a new session for 
each new incoming request. The mon script of course doesn't store cookies, so 
each time it checks if httpd is alive it gets a new session. 

Well, glad I have that resolved. Thanks to me for solving my prob, and thanks 
to the persistent perl team for the *right* solution :-)

++Lorenzo;


On Monday 17 February 2003 20:32, Lorenzo Danielsson wrote:
> Hi,
>
> I've run into a small problem using speedy with a virtual host setup. Now I
> know that a long time ago I read something about speedy and virtual hosts.
> But today I've tried searching to no avail (I'm on a sloooow dialup, google
> doesn't load, alltheweb times out during search). I can't even remember
> what the doc said because virtual hosting was a foreign concept to me at
> the time.
>
> I'm working on a system for managing software projects (something like
> sourceforge but smaller in scope). I've written my own session management
> stuff. Everything seems to works. But the other day I added some (name)
> virtual hosts to my apache config. Now what I have is a new session (in my
> sessions) table being created approx every 2 minutes.
>
> I've tried to rtfm, but no luck. I don't have the speedy sources because I
> made a mistake a downloaded redhat rpms. I no expert on apache
> configuration, so I could definately be doing something odd there..
>
> Now could somebody pls let me know what is going on? Am I doing anything
> wrong? (apache config perhaps?). If not, is there any way I can solve it?
>
> I really hope so, because I'm really happy using speedy. I don't want
> mod_perl eating my RAM, FastCGI is also not really *right*, and I don't
> want to have to start doing php.
>
> Btw, RH7.3, apache-1.3.23, speedy-2.21.
>
> Regards,
> ++Lorenzo;
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Persistentperl-users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/persistentperl-users

[Persistentperl-users] speedy/perperl on virtual host probs.

[Lorenzo D. <Lor...@fl...>]

Hi,

I've run into a small problem using speedy with a virtual host setup. Now I 
know that a long time ago I read something about speedy and virtual hosts. 
But today I've tried searching to no avail (I'm on a sloooow dialup, google 
doesn't load, alltheweb times out during search). I can't even remember what 
the doc said because virtual hosting was a foreign concept to me at the time.

I'm working on a system for managing software projects (something like 
sourceforge but smaller in scope). I've written my own session management 
stuff. Everything seems to works. But the other day I added some (name) 
virtual hosts to my apache config. Now what I have is a new session (in my 
sessions) table being created approx every 2 minutes. 

I've tried to rtfm, but no luck. I don't have the speedy sources because I 
made a mistake a downloaded redhat rpms. I no expert on apache configuration, 
so I could definately be doing something odd there..

Now could somebody pls let me know what is going on? Am I doing anything 
wrong? (apache config perhaps?). If not, is there any way I can solve it?

I really hope so, because I'm really happy using speedy. I don't want mod_perl 
eating my RAM, FastCGI is also not really *right*, and I don't want to have 
to start doing php.

Btw, RH7.3, apache-1.3.23, speedy-2.21.

Regards,
++Lorenzo;

Re: [Persistentperl-users] Indefinite wait on first pass through?

[Sam H. <sa...@da...>]

The five minute hang is probably a file that is being held onto either
by your perl script, or by a process you spawn (like oracle).  The five
minutes isn't being consumed by one part of your code or the other,
it's the web server thinking that your code is still running even after
it's done, because you still have an open file.  At least that's my best
guess from what I've seen so far.

If you could start tearing parts of your code out in testing, like remove
the oracle database open altogether, or remove other parts where you may
dup files or spawn other processes, and see if the hang goes away, you
could probably narrow it down that way, to see which part is causing it.

To answer your question, here's what your main program should look like:

 #!/usr/bin/perperl
 &log("step1");
 $query = new CGI;

 &log("step2");
 &process_request();

 &log("step3");

No while loop is required.  There's no need to call exit.  If your
script is written correctly you should be able to switch from "perperl"
to "perl" with no changes to the code.



 > Hi Sam,
 > 
 > Todd & I have narrowed down the issue a bit, but we could still use your advice.  We added
 > timing/debug/log statements to our core software and it revealed a few things.  It is not really an
 > Oracle issue.  I think it is more related to how we get and process the CGI request and if our main
 > program should ever exit(0)?  Here's what we've found:
 > 
 > 1) background info:  a small version of our code is:
 > #!/usr/bin/perperl -X -- -M1 -t604800
 > MAIN:
 > {
 >     &log("step1");
 >       $query = new CGI;
 > 
 >     &log("step2");
 >      &process_request();
 > 
 >     &log("step3");
 >      #    exit(0);
 > }
 > 
 > sub process_request
 > {
 > .... our main application here...
 > }
 > 
 > where process_request(); is the bulk of our program.
 > 
 > It flies through steps 1,2,3 within 1-3 seconds.... then after step3, it hangs for 5 minutes... if we
 > add the exit(0), it still hangs...
 > 
 > If we recraft the code to be:
 > MAIN:
 > {
 >     &log("step1");
 > 
 >     while(1) {
 >      $query = new CGI;
 >      &log("step2");
 > 
 >      &process_request();
 >      &log("step3");
 >    }
 > }
 > 
 > Then it processes the first request over & over again, but really quickly....
 > 
 > If we recraft the code to be:
 > MAIN:
 > {
 >     &log("step1");
 > 
 >     while($query = new CGI) {
 >      &log("step2");
 > 
 >      &process_request();
 >      &log("step3");
 >    }
 > }
 > 
 > Then it takes the long time to process even the first request...
 > 
 > My guess is that we should be putting this into a loop or not using "new CGI" but using something like
 > CGI::Request() or something.  Can you e-mail us a 5 line sample script on what you had in mind?  I'm
 > sure it's some confusion about how the main loop should either poll forever, or exit and what CGI::
 > method you (the perperl code) is expecting us to use.
 > 
 > Many thanks,
 > 
 > Joel
 > 
 > 
 > ______________________________________
 > Joel Plotkin
 > eJournalPress
 > http://www.ejournalpress.com
 > 301-254-5900
 > 301-564-4006 (fax)
 > 
 > 
 > 
 > 
 > 
 > --------------87E8EBFE6E648645532F8BFB
 > Content-Type: text/html; charset=us-ascii
 > Content-Transfer-Encoding: 7bit
 > 
 > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 > <html>
 > Hi Sam,
 > <p>Todd &amp; I have narrowed down the issue a bit, but we could still
 > use your advice.&nbsp; We added timing/debug/log statements to our core
 > software and it revealed a few things.&nbsp; It is not really an Oracle
 > issue.&nbsp; I think it is more related to how we get and process the CGI
 > request and if our main program should ever exit(0)?&nbsp; Here's what
 > we've found:
 > <p>1) background info:&nbsp; a small version of our code is:
 > <br>#!/usr/bin/perperl -X -- -M1 -t604800
 > <br><tt>MAIN:</tt>
 > <br><tt>{</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp; &amp;log("step1");</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $query = new CGI;</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp; &amp;log("step2");</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;process_request();</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp; &amp;log("step3");</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; exit(0);</tt>
 > <br><tt>}</tt><tt></tt>
 > <p><tt>sub process_request</tt>
 > <br><tt>{</tt>
 > <br><tt>.... our main application here...</tt>
 > <br><tt>}</tt>
 > <p>where process_request(); is the bulk of our program.
 > <p>It flies through steps 1,2,3 within 1-3 seconds.... then after step3,
 > it hangs for 5 minutes... if we add the exit(0), it still hangs...
 > <p>If we recraft the code to be:
 > <br><tt>MAIN:</tt>
 > <br><tt>{</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp; &amp;log("step1");</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp; while(1) {</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; $query = new CGI;</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;log("step2");</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;process_request();</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;log("step3");</tt>
 > <br><tt>&nbsp;&nbsp; }</tt>
 > <br><tt>}</tt>
 > <p>Then it processes the first request over &amp; over again, but really
 > quickly....
 > <p>If we recraft the code to be:
 > <br><tt>MAIN:</tt>
 > <br><tt>{</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp; &amp;log("step1");</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp; while($query = new CGI) {</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;log("step2");</tt><tt></tt>
 > <p><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;process_request();</tt>
 > <br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &amp;log("step3");</tt>
 > <br><tt>&nbsp;&nbsp; }</tt>
 > <br><tt>}</tt>
 > <p>Then it takes the long time to process even the first request...
 > <p>My guess is that we should be putting this into a loop or not using
 > "new CGI" but using something like CGI::Request() or something.&nbsp; Can
 > you e-mail us a 5 line sample script on what you had in mind?&nbsp; I'm
 > sure it's some confusion about how the main loop should either poll forever,
 > or exit and what CGI:: method you (the perperl code) is expecting us to
 > use.
 > <p>Many thanks,
 > <p>Joel
 > <br>&nbsp;
 > <p>______________________________________
 > <br>Joel Plotkin
 > <br>eJournalPress
 > <br><A HREF="http://www.ejournalpress.com">http://www.ejournalpress.com</A>
 > <br>301-254-5900
 > <br>301-564-4006 (fax)
 > <br>&nbsp;
 > <br>&nbsp;
 > <br>&nbsp;
 > <br>&nbsp;</html>
 > 
 > --------------87E8EBFE6E648645532F8BFB--
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
 > are you planning your Web Server Security? Click here to get a FREE
 > Thawte SSL guide and find the answers to all your  SSL security issues.
 > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
 > _______________________________________________
 > Persistentperl-users mailing list
 > Per...@li...
 > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
 > 

Re: [Persistentperl-users] Indefinite wait on first pass through?

[Joel P. <pl...@ej...>]

Hi Sam,

Todd & I have narrowed down the issue a bit, but we could still use your advice.  We added
timing/debug/log statements to our core software and it revealed a few things.  It is not really an
Oracle issue.  I think it is more related to how we get and process the CGI request and if our main
program should ever exit(0)?  Here's what we've found:

1) background info:  a small version of our code is:
#!/usr/bin/perperl -X -- -M1 -t604800
MAIN:
{
    &log("step1");
      $query = new CGI;

    &log("step2");
     &process_request();

    &log("step3");
     #    exit(0);
}

sub process_request
{
.... our main application here...
}

where process_request(); is the bulk of our program.

It flies through steps 1,2,3 within 1-3 seconds.... then after step3, it hangs for 5 minutes... if we
add the exit(0), it still hangs...

If we recraft the code to be:
MAIN:
{
    &log("step1");

    while(1) {
     $query = new CGI;
     &log("step2");

     &process_request();
     &log("step3");
   }
}

Then it processes the first request over & over again, but really quickly....

If we recraft the code to be:
MAIN:
{
    &log("step1");

    while($query = new CGI) {
     &log("step2");

     &process_request();
     &log("step3");
   }
}

Then it takes the long time to process even the first request...

My guess is that we should be putting this into a loop or not using "new CGI" but using something like
CGI::Request() or something.  Can you e-mail us a 5 line sample script on what you had in mind?  I'm
sure it's some confusion about how the main loop should either poll forever, or exit and what CGI::
method you (the perperl code) is expecting us to use.

Many thanks,

Joel


______________________________________
Joel Plotkin
eJournalPress
http://www.ejournalpress.com
301-254-5900
301-564-4006 (fax)

[Persistentperl-users] Using PersistentPerl on AIX and HP-UX

[<Jes...@va...>]

Hi Sam and others,

I'm trying to get PersistentPerl running on AIX 4.3.3 and HP-UX 11.0, has
anyone else tried this?

Results so far: Compiling on AIX 4.3.3 works as soon as I add
/usr/lib/crt0.o explicitly to the OBJECT list, (Otherwise ld complains
about there being no __start symbol in the resulting binary)
make test runs ok, the only things that fail are two of the stdio tests,
two of the stdio2 tests and one of the stdio_close tests - should I be
worried about these?
Havent tried actually running anything yet ;)
(Compiler: AIX' 'xlC')

Compiling on HP-UX 11.0 works after I delete the explicit '-Wl,-E'
parameters in the perperl and perperl_backend Makefiles, HP-UX's ld doesnt
like those (why isnt the $CCDLFLAGS variable used there? or is that a
MakeMaker problem?) (the /usr/lib/crt0.o addin from above was also still
active)
make test fails completely unfortunately, lots of error messages like:

PERL_DL_NONLAZY=1
PERPERL=/home/mis/jer/perl/src/PersistentPerl-2.21/perperl/pe
 rperl
PERPERL_BACKENDPROG=/home/mis/jer/perl/src/PersistentPerl-2.21/perperl_ba
 ckend/perperl_backend
PERPERL_MODULE=/home/mis/jer/perl/src/PersistentPerl-2.21
 // PERPERL_TIMEOUT=300 /usr/local/new/bin/perl -I../blib/arch
-I../blib/lib -I/
 usr/local/packages/perl-5.6.1/lib/5.6.1/PA-RISC2.0
-I/usr/local/packages/perl-5
 .6.1/lib/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0;
runtes
 ts @ARGV;' t/*.t
 t/alarm.............perperl[20794]: Cannot spawn backend process
 perperl[20804]: Cannot spawn backend process
 Argument "" isn't numeric in addition (+) at t/alarm.t line 16.
 perperl[20813]: Cannot spawn backend process
 Argument "" isn't numeric in addition (+) at t/alarm.t line 18.
 FAILED test 2
         Failed 1/2 tests, 50.00% okay
 t/argv..............perperl[20820]: Cannot spawn backend process
... etc. pp.

and a lovely big core-file in /tmp, so I guess the backend dies somewhere..
This was using a cc in /opt/ansic/bin/cc which is what /usr/bin/cc is
pointing to, sorry Ive no idea at the moment which that is, but its not
gcc.

Any tips, ideas before I go looking at the source code?

Thanks,

Jess

PS: Did you know theres a PPerl out there? (Though it fails even worse on
AIX and HP-UX...)

Re: [Persistentperl-users] Indefinite wait on first pass through?

[Sam H. <sa...@da...>]

 I think oracle usually uses ipc to connect to the database, when the
 database is on the same system as the client.  But if your database is on
 a different box, you must be using TCP/IP.

 From your description of the problem, it sounds like the oracle problem
 or something similar.  Do you fork any programs that continue running
 even after your perl code is done?  That's what oracle does, and that's
 why it can hang up a backend.  The background oracle process keeps stdout
 open, and since that file is a pipe into the web-server, the web-server
 never sees an EOF on the script's stdout, and just waits, and eventually
 times out.

 You could try applying the close-on-exec fcntl on STDERR in addition to
 STDOUT.  That might fix it if there is a forked program holding onto
 that file.

 Or, if you dupe STDERR/STDOUT in your perl code and don't close the duped
 file before exiting, that might be causing the hang.

 I think the five minute thing is due to your web server's cgi timeout.
 After five minutes, the web server gives up on the cgi altogether, and
 displays the results, even if the cgi hasn't shut down stdout and stderr.

 > Right; but i'm not specifically using an IPC connection to the database.
 > Or am I?  Why would i use anything except a TCP connection if i'm on
 > a TCP/IP network?  I'm not ever compiling in an IPC module and i'm on a 
 > standard tcp/ip network.

 > Nonetheless, i put in the fcntl call into the code for testing and am now
 > seeing very odd results.  I have two browser windows open; i touch the
 > main perl program w/ the perperl call and hit reload in browser window one:
 > it starts spinning, saying its "Opening page http://..."  Meanwhile,
 > as Soon as you hit reload in browser 1, you can open the page in browser
 > two and it works like a charm.  Fully FIVE minutes later the first browser
 > comes up.  Five minutes??  AFter this, both browsers work jsut fine.
 > This behavior is repeatable ... its about 5:15 each time.
 > 
 > Any ideas?  The perl code loaded up totals 271790 lines (pretty big) and the
 > image size of each perperl_backend process is 70Mb.  Could it just be that
 > the code is so big and complex that it just takes 5 minutes for perperl to
 > store the first time through (and if this is the case...why does the 
 > SECOND load attempt work so well, WHILE the first load attempt is still
 > going on?).  I killed all backends inbetween tests to prevent a "cached"
 > backend from servicing the program and got the same results.
 > 
 > 
 > As for #2, i fixed the bug that was causing it (there were ^M characters
 > in a module we were using ...) and now i can't recreate it necessarily.
 > What was happening was, our code ran fine until it tried to read in
 > the module w/ the bug.  I'll have to dig to re-create it.
 > 
 > Any insight anyone can provide is greatly appreciated.  
 > Thanks, todd
 > 
 > 
 > > 
 > > There is a known issue with DBI::Oracle causing hangs like that if you're
 > > using IPC for your oracle connection.  A workaround is provided in the
 > > last question under "Frequently Asked Questions".
 > > 
 > > As for #2, does the compile fail initially when the script is first
 > > loaded, or is it later on in an eval, do or require?  Can you provide a small
 > > code example that demonstrates the problem?
 > > 
 > >  > Hello all
 > >  > 
 > >  > (I see the bandwidth on this list is pretty low ... 4 messages in a 
 > >  > year, so i hope there's still people out there).
 > >  > 
 > >  > We've installed perperl on a Solaris box using Iplanet webserver
 > >  > and are running into two critical issues.
 > >  > 
 > >  > #!/usr/bin/perperl -X -- -M1 -t604800 
 > >  > is the options we're using.
 > >  > 
 > >  > 1. The first time a web browser connects to the website running perperl,
 > >  > the browser never pulls the site up.  You have to physically hit the
 > >  > stop and reload buttons on the browser (doesn't matter what browser)
 > >  > before the site comes up.  After that things are fine.  We can repeat
 > >  > this process at will by touching the main perl program that runs.
 > >  > 
 > >  > 2. If there is a compilation error in the code ... the perperl process
 > >  > can't ever load a page again ... we either have to kill the backend
 > >  > processes or touch the main perl program to force the backends to 
 > >  > reload... which of course causes us the issue in point #1.
 > >  > 
 > >  > Does anyone have any insight into why this is happening?  We've
 > >  > tried setting timeout to Zero and then to a large number to no avail.
 > >  > We're doing database connections via DBI:Oracle in the code as 
 > >  > well, if that is known to be problematic.
 > >  > 
 > >  > Thanks, todd
 > >  > 
 > >  > 
 > >  > -------------------------------------------------------
 > >  > This SF.NET email is sponsored by:
 > >  > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 > >  > http://www.vasoftware.com
 > >  > _______________________________________________
 > >  > Persistentperl-users mailing list
 > >  > Per...@li...
 > >  > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
 > >  > 
 > > 
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.NET email is sponsored by:
 > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 > http://www.vasoftware.com
 > _______________________________________________
 > Persistentperl-users mailing list
 > Per...@li...
 > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
 > 

Re: [Persistentperl-users] Indefinite wait on first pass through?

[boss <bo...@sh...>]

Right; but i'm not specifically using an IPC connection to the database.
Or am I?  Why would i use anything except a TCP connection if i'm on
a TCP/IP network?  I'm not ever compiling in an IPC module and i'm on a 
standard tcp/ip network.

Nonetheless, i put in the fcntl call into the code for testing and am now
seeing very odd results.  I have two browser windows open; i touch the
main perl program w/ the perperl call and hit reload in browser window one:
it starts spinning, saying its "Opening page http://..."  Meanwhile,
as Soon as you hit reload in browser 1, you can open the page in browser
two and it works like a charm.  Fully FIVE minutes later the first browser
comes up.  Five minutes??  AFter this, both browsers work jsut fine.
This behavior is repeatable ... its about 5:15 each time.

Any ideas?  The perl code loaded up totals 271790 lines (pretty big) and the
image size of each perperl_backend process is 70Mb.  Could it just be that
the code is so big and complex that it just takes 5 minutes for perperl to
store the first time through (and if this is the case...why does the 
SECOND load attempt work so well, WHILE the first load attempt is still
going on?).  I killed all backends inbetween tests to prevent a "cached"
backend from servicing the program and got the same results.


As for #2, i fixed the bug that was causing it (there were ^M characters
in a module we were using ...) and now i can't recreate it necessarily.
What was happening was, our code ran fine until it tried to read in
the module w/ the bug.  I'll have to dig to re-create it.

Any insight anyone can provide is greatly appreciated.  
Thanks, todd


> 
> There is a known issue with DBI::Oracle causing hangs like that if you're
> using IPC for your oracle connection.  A workaround is provided in the
> last question under "Frequently Asked Questions".
> 
> As for #2, does the compile fail initially when the script is first
> loaded, or is it later on in an eval, do or require?  Can you provide a small
> code example that demonstrates the problem?
> 
>  > Hello all
>  > 
>  > (I see the bandwidth on this list is pretty low ... 4 messages in a 
>  > year, so i hope there's still people out there).
>  > 
>  > We've installed perperl on a Solaris box using Iplanet webserver
>  > and are running into two critical issues.
>  > 
>  > #!/usr/bin/perperl -X -- -M1 -t604800 
>  > is the options we're using.
>  > 
>  > 1. The first time a web browser connects to the website running perperl,
>  > the browser never pulls the site up.  You have to physically hit the
>  > stop and reload buttons on the browser (doesn't matter what browser)
>  > before the site comes up.  After that things are fine.  We can repeat
>  > this process at will by touching the main perl program that runs.
>  > 
>  > 2. If there is a compilation error in the code ... the perperl process
>  > can't ever load a page again ... we either have to kill the backend
>  > processes or touch the main perl program to force the backends to 
>  > reload... which of course causes us the issue in point #1.
>  > 
>  > Does anyone have any insight into why this is happening?  We've
>  > tried setting timeout to Zero and then to a large number to no avail.
>  > We're doing database connections via DBI:Oracle in the code as 
>  > well, if that is known to be problematic.
>  > 
>  > Thanks, todd
>  > 
>  > 
>  > -------------------------------------------------------
>  > This SF.NET email is sponsored by:
>  > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>  > http://www.vasoftware.com
>  > _______________________________________________
>  > Persistentperl-users mailing list
>  > Per...@li...
>  > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
>  > 
> 

Re: [Persistentperl-users] Indefinite wait on first pass through?

[Sam H. <sa...@da...>]

There is a known issue with DBI::Oracle causing hangs like that if you're
using IPC for your oracle connection.  A workaround is provided in the
last question under "Frequently Asked Questions".

As for #2, does the compile fail initially when the script is first
loaded, or is it later on in an eval, do or require?  Can you provide a small
code example that demonstrates the problem?

 > Hello all
 > 
 > (I see the bandwidth on this list is pretty low ... 4 messages in a 
 > year, so i hope there's still people out there).
 > 
 > We've installed perperl on a Solaris box using Iplanet webserver
 > and are running into two critical issues.
 > 
 > #!/usr/bin/perperl -X -- -M1 -t604800 
 > is the options we're using.
 > 
 > 1. The first time a web browser connects to the website running perperl,
 > the browser never pulls the site up.  You have to physically hit the
 > stop and reload buttons on the browser (doesn't matter what browser)
 > before the site comes up.  After that things are fine.  We can repeat
 > this process at will by touching the main perl program that runs.
 > 
 > 2. If there is a compilation error in the code ... the perperl process
 > can't ever load a page again ... we either have to kill the backend
 > processes or touch the main perl program to force the backends to 
 > reload... which of course causes us the issue in point #1.
 > 
 > Does anyone have any insight into why this is happening?  We've
 > tried setting timeout to Zero and then to a large number to no avail.
 > We're doing database connections via DBI:Oracle in the code as 
 > well, if that is known to be problematic.
 > 
 > Thanks, todd
 > 
 > 
 > -------------------------------------------------------
 > This SF.NET email is sponsored by:
 > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
 > http://www.vasoftware.com
 > _______________________________________________
 > Persistentperl-users mailing list
 > Per...@li...
 > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
 > 

[Persistentperl-users] Indefinite wait on first pass through?

[boss <bo...@sh...>]

Hello all

(I see the bandwidth on this list is pretty low ... 4 messages in a 
year, so i hope there's still people out there).

We've installed perperl on a Solaris box using Iplanet webserver
and are running into two critical issues.

#!/usr/bin/perperl -X -- -M1 -t604800 
is the options we're using.

1. The first time a web browser connects to the website running perperl,
the browser never pulls the site up.  You have to physically hit the
stop and reload buttons on the browser (doesn't matter what browser)
before the site comes up.  After that things are fine.  We can repeat
this process at will by touching the main perl program that runs.

2. If there is a compilation error in the code ... the perperl process
can't ever load a page again ... we either have to kill the backend
processes or touch the main perl program to force the backends to 
reload... which of course causes us the issue in point #1.

Does anyone have any insight into why this is happening?  We've
tried setting timeout to Zero and then to a large number to no avail.
We're doing database connections via DBI:Oracle in the code as 
well, if that is known to be problematic.

Thanks, todd

Re: [Persistentperl-users] Behavior of Maxbackends

[Sam H. <sa...@da...>]

 > When # of backends reaches MaxBackends, what happens?  Does the frontend
 > terminate?  Does it wait?

 The frontend waits indefinitely.

[Persistentperl-users] Behavior of Maxbackends

[Jonathan B. <jo...@es...>]

When # of backends reaches MaxBackends, what happens?  Does the frontend
terminate?  Does it wait?

Thanks in advance,

Jonathan Bartlett

[Persistentperl-users] PersistentPerl release 2.21

[Sam H. <sa...@da...>]

PersistentPerl release 2.21 is available at:

    http://daemoninc.com/PersistentPerl/download.html

The changes since 2.20 are:

	- Fix too many backends problem reported by Theo Petersen.  The
	  problem is due to temp-file corruption that occurs when the
	  web-server sends a TERM signal to the frontend while it is working
	  on the temp file.  It also results in some backends failing due
	  to the corruption.  Added a fix so that signals are always blocked
	  while working on the temp file.

	- Shutdown handler should be called after script is touched.

	- Fixes for Mac OS X 10.1.  Workaround the sigpending() bug,
	  and add msync() which appears to fix a shared-memory flushing
	  problem when temp-file is expanded.

[Persistentperl-users] PersistentPerl release 2.21

[Sam H. <sa...@da...>]

PersistentPerl release 2.21 is available at:

    http://daemoninc.com/PersistentPerl/download.html

The changes since 2.20 are:

	- Fix too many backends problem reported by Theo Petersen.  The
	  problem is due to temp-file corruption that occurs when the
	  web-server sends a TERM signal to the frontend while it is working
	  on the temp file.  It also results in some backends failing due
	  to the corruption.  Added a fix so that signals are always blocked
	  while working on the temp file.

	- Shutdown handler should be called after script is touched.

	- Fixes for Mac OS X 10.1.  Workaround the sigpending() bug,
	  and add msync() which appears to fix a shared-memory flushing
	  problem when temp-file is expanded.

[Persistentperl-users] New user

[<ta...@se...>]

Hello,

I've joined this mailing list today.
And I really want to say thanks to authers,
'cause I'm very glad to use this module.

Many people are using mod_perl to gain many
advantages, but my company does'nt use mod_perl,
even though some Apaches are running.
Many applications are made by java and I must make
mere CGI when I have to make in perl in iWS
(iPlanet Web Server).
I'm happy to know persitentperl can be run on iWS.

These are my 2 long-searching technology on perl CGI
on iWS;
1. mod_perl like technology.
2. JSP(java server page) like technology.

CAPN module PLP by Mr.Juerd Waalboer is what I really
want but it cann't be run on iWS.
HTML::Template is usefull but not enough.

Anyway perperl is one of two...

Regards,
Hirosi Taguti
ta...@se...