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
 >