RE: loss of shared memory in parent httpd
Hi, I had hoped that FreeBSD would be immune, but it seems not. I have been bashing it with http_load and all of a sudden(after a LOT of bashing and swaping) all of my processes had zero shared. It did take me days of fiddling to run into this though. Thanks, Eric At 04:16 PM 3/16/02 -0500, Ed Grimm wrote: I believe I have the answer... The problem is that the parent httpd swaps, and any new children it creates load the portion of memory that was swaped from swap, which does not make it copy-on-write. The really annoying thing - when memory gets tight, the parent is the most likely httpd process to swap, because its memory is 99% idle. This issue aflicts Linux, Solaris, and a bunch of other OSes. The solution is mlockall(2), available under Linux, Solaris, and other POSIX.1b compliant OSes. I've not experimented with calling it from perl, and I've not looked at Apache enough to consider patching it there, but this system call, if your process is run as root, will prevent any and all swapping of your process's memory. If your process is not run as root, it returns an error. The reason turning off swap works is because it forces the memory from the parent process that was swapped out to be swapped back in. It will not fix those processes that have been sired after the shared memory loss, as of Linux 2.2.15 and Solaris 2.6. (I have not checked since then for behavior in this regard, nor have I checked on other OSes.) Ed On Thu, 14 Mar 2002, Bill Marrs wrote: It's copy-on-write. The swap is a write-to-disk. There's no such thing as sharing memory between one process on disk(/swap) and another in memory. agreed. What's interesting is that if I turn swap off and back on again, the sharing is restored! So, now I'm tempted to run a crontab every 30 minutes that turns the swap off and on again, just to keep the httpds shared. No Apache restart required! Seems like a crazy thing to do, though. You'll also want to look into tuning your paging algorithm. Yeah... I'll look into it. If I had a way to tell the kernel to never swap out any httpd process, that would be a great solution. The kernel is making a bad choice here. By swapping, it triggers more memory usage because sharing removed on the httpd process group (thus multiplied)... I've got MaxClients down to 8 now and it's still happening. I think my best course of action may be a crontab swap flusher. -bill http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone)
Re: loss of shared memory in parent httpd (2)
Hi, This may be totaly ignorate crap, but I noticed this when I was reading the ps man page on BSD 4.5 about sys/proc.h flags This one I noticed.. P_SYSTEM 0x00200System proc: no sigs, stats or swapping Could this mean what I think it means? That a process with this flag set, won't be swaped out?? Thanks, Eric At 03:55 PM 3/12/02 +0100, Elizabeth Mattijsen wrote: Oops. Premature sending... I have two ideas that might help: - reduce number of global variables used, less memory pollution by lexicals - make sure that you have the most up-to-date (kernel) version of your OS. Newer Linux kernels seem to be a lot savvy at handling shared memory than older kernels. Again, I wish you strength in fixing this problem... Elizabeth Mattijsen http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone)
Apache::DBI or What ?
Hi, I was all happy and rolling along when I read this in the docs. With this limitation in mind, there are scenarios, where the usage of Apache::DBI is depreciated. Think about a heavy loaded Web-site where every user connects to the database with a unique userid. Every server would create many database handles each of which spawning a new backend process. In a short time this would kill the web server. I will have many different users, users as in database users. So am I just screwed and won't be able to keep connections open? Or maybe the idea would be to go ahead and let that happen, but timeout the connection in 5 mintues or so? That way I wouldn't have open connectoins from user bob from 5 hours ago still siting around. Or am I totaly not getting it at all? I am using Postgress, I am wondering how big DBs deal with this sort of thing. I am also wondering what the actual overhead is in starting the connection and if there is anything that I could to to limit that without validating a specific user. Last of all, I might not be posting this to the right place, but I hope so. It seems to me there is a grey area when it comes to Apache modules when you are using them with mod_perl. Or else I just don't know enough yet to see there is not a grey area :) Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone)
Re: Apache::DBI or What ?
Hi, It might well be that in my particular case, I don't have anything to worry about the connection time per each user most likely won't kill me or even cause problems at first. But I am trying to build a system, and I don't want to skip any reasonable efficences I can build in from the start. In my situation the user will only be doing inserts from the mod_perl side, so I am thinking I can make use of something like Apache::File or some kind of tmp file where I will store the tab delimited data for the user insert, and on the cleanup handler phase does a COPY FROM file which is a Postgress thing to the user's table. I need for that data to be available to that same user by JDBC pretty much immediatly. But does a copy from a file like this work better than a persistent connection but one that is doing insert after insert which is not nearly as efficent as the bulk copy? As I understand it the COPY from after a droping indexes would be the fastest way to insert data into a table for postgress, period. I guess I will just have to test it out and see. The other thing I am wondering about, is that even if I have a bunch of users, why couldn't I just make my persistent connection user have rights to all of the other user tables? Well, I guess I could do that, but I am expecting one of you will tell me why that is a bad idea :) Something about it seem too easy after all of this. I was tending to want to use the DBs security also for the same reasons, so maybe that is what bothers me about the above. Thanks, this discussion has helped me out tremendously, just to know others have the same problem even. Eric First, I'll suggest that there are hopefully other areas you can look at optimizing that will get you a bigger bang for your time - in my test environment (old hardware), it takes 7.4 ms per disconnect/reconnect/rebind and 4.8 ms per rebind. Admittedly, I'm dealing with LDAP instead of SQL, and I've no idea how they compare. If the TCP connection were retained, this could still be a significant win. *Any* reduction in the connection overhead is an improvement. If there are a million connects per day, and this saves a milli-second per connect (believable to me, as at least three packets don't need to be sent - syn, syn ack, and fin. My TCP's a bit fuzzy, but I think there's a couple more, and there's also the mod_perl disconnect/reconnect overhead), that's over 15 minutes of response time and about 560,000,000 bits of network bandwidth (assuming the DB is not on the same machine) saved. Admittedly, at 100Mb/s, that's only 6 seconds. It may, in some cases, still be necessary to move access control from the DB into ones application, so one can maintain a single connection which never rebinds, but I think it's better to utilize the security in the DB instead of coding ones own - more eyes have looked over it. We're talking about a fairly small unit of time; it may very well be better to throw money if you are near your performance limit. Ed http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone)
Re: Apache::DBI or What ?
Hi, If you have any idea where to find this code I would be thankful. I can only find this.. http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI/298774 Thanks, Eric At 04:47 PM 3/26/02 -0500, John D Groenveld wrote: There are databases that allow you to change the current user without reconnecting. In fact someone posted a module to do this a while back, but I can't remember which database it was for. Seems like it was Sybase or Informix. Jeff Horn posted this a couple years ago either here or @ dbi-users # Hacked Up Version of Apache::DBI # # Hacking by: Jeff Horn ([EMAIL PROTECTED]) # # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on # subsequent connect calls, the DBI-func( ., ., 'reauthtenticate') # is called to quickly authenticate the new user on the existing # connection. I've used it for a few projects, I haven't really follow how changes over the last year to Edmund Mergl's Apache::DBI or Tim Bunce's DBI may have affected it. I recall one problem being when using different attributes to connect methods. Have fun. John [EMAIL PROTECTED] http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: Apache::DBI or What ?
Hi! Thanks a lot for this. I am not sure now if I will be able to use it. I am afraid that if I do I will suddenly become its main supporter :) I also still don't see how a connection can be reconnected at such a high level. Even when I looked into the mySQL C api I didn't see anything that would help, which ment that the real stuff was barried deeper still. But the caching of connection handles makes sense, and that might still be worth while. Between this and mod_accel I have a lot to mess with. Thanks, Eric At 01:52 PM 3/30/02 -0500, Hank Leininger wrote: On 2002-03-27, Eric Frazier [EMAIL PROTECTED] wrote: If you have any idea where to find this code I would be thankful. I can only find this.. [snip] At 04:47 PM 3/26/02 -0500, John D Groenveld wrote: Jeff Horn posted this a couple years ago either here or @ dbi-users # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on Ask and ye shall receive ;) http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181w=2 Or just grab the last attachment, which is the replacement DBI.pm: http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181q=p6 -- Hank Leininger [EMAIL PROTECTED] http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Equiv Apache list to this list?
Hi, I have been having lots of questions about Apache recently, not many of them are really mod_perl questions, so what is the best place to post those? Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
XML::RPC
Hi, I am finally finding yes, there could be a reason for me to use this, I want to avoid SOAP, partly because of the license crap(fear), but also because I figure that XMLRPC will be easier to learn at first and likely will fit my small needs. But as I look at examples and various tools that support working with Perl they often are of a nature of a CGI and a standalone client. My needs aren't that small :) The only Apache modules I have found are with the SOAP::Lite module. So what do the you people recommend? I have found several, Frontier::RPC, there is a SOAP::Lite XML::RPC module, but it depends on SOAP::Lite which I find confusing, there is just RPC::XML on CPAN. Most important though, I of course want to run the server with mod_perl which is the only reason I consider this post to be somewhat on topic, I really want to use mod_perl with this and what group would be better to advise me on that :) What I want to be able to do is to expose some simple method calls, along with some hash data to a Java client. Say like a parser object from HTML::Parser. The client will be Java, but I get the idea that shouldn't really matter. Sorry if my terminology is off, I am swimming a bit.. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: XML::RPC
I forgot one, http://sourceforge.net/projects/mod-xmlrpc/ But it isn't exactly well documented for a non C programmer. It looks like it might be an option. Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: XML::RPC
Hi, The warning is nice, but it isn't that useful. Do you have an alternative? I am not looking to do great things, just get a Java client to be able to do a few method calls, and to accept a XML encoded hash of perl data. It is a fairly complex hash though. So I really don't know of another way to send this data. Perhaps if I get rid of the method calls and just use Registry, and then hand encode the XML hash with perl that would make you feel better? I still have to deal with auth and I don't see how a SOAP server is any less secure than the server itself is considering every request will be authenticated, no open server stuff, no requests that I don't know who they are coming from. But I am learning, so I am happy to learn more. It is just that your comments seem pretty general. Thanks, Eric At 11:46 AM 4/21/02 +0100, Matthew Byng-Maddick wrote: On Sun, Apr 21, 2002 at 01:06:28PM +0200, F. Xavier Noria wrote: On Sun, 21 Apr 2002 10:50:53 +0100 Matthew Byng-Maddick [EMAIL PROTECTED] wrote: : On Sun, Apr 21, 2002 at 03:16:53AM -0400, Sam Tregar wrote: : SOAP::Lite module to be of excelent quality and the SOAP::Lite community : to be very helpful. : Apart from the obvious security bug, you mean? The one where it doesn't : actually restrict what remote code can be run at all? SOAP::Lite 0.55 was released some days ago, it addresses that issue according to http://www.soaplite.com/ I'm aware of this, but I can't stress the importance of reviewing such security-critical code. And the excellent quality of the code that was mentioned by Sam Tregar in his post. RPC often is a nightmare security-wise, the SOAP::Lite bug illustrates the problems perfectly. MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/ http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: XML::RPC
Hi, Thanks, the thing that scared me about RPC::XML was the 0.37 version number :) I will give it a serious try before I go to something like SOAP. Within RPC::XML: Apache::RPC::Server - A subclass of RPC::XML::Server tuned for mod_perl I didn't see this until now. :) Getting warm fuzzy feeling now. Thanks again, Eric I think you'll find RPC::XML to be a solidly engineered module. I've used it as a client and as a server to good effect. It includes stand-alone, CGI, and mod_perl based servers and a very nice client. If all you need is simple RPC calls I find that XML-RPC provides a much more straightforward environment. Even with my background in http based rpc systems it took me a while to pick up on the idiosyncrasies of SOAP. -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org/ Human Rights Declaration http://www.unhchr.ch/udhr/ http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Building high load mod_perl/Mason servers
Hi, I just got the chance to be in charge of a very busy website, and its future growth. Currently it is running with PHP on two round robin servers with a separate mysql db server. We are going to be moving to mod_perl, but I am worried about how to keep from getting into the same kind of trap with mod_perl as with PHP. The PHP guys don't know OOP, so we have to code halfway, modules exporter but not OOP modules. It has to be something OOP like without getting too complex at first. The PHP trap is just the horrible require once stuff all over the place and global vars etc. I know lots of people blame this kind of coding on perl geeks, but the PHP stuff I have been seeing is pretty bad with it because the constant thought is must fix current problem wait till later to be pretty but later never comes. Also things like using ten instr functions instead of one reg exp. So I am thinking whatever I do it should fit within an existing framework, something like Mason. But I am confused about what real advatage Mason provides, and how things like source code control would work if we are running lots of servers. Do people use rsync to keep up to date? Say one machine is always the upload point and the rest get synced from that one? I am having a hard time asking really good questions I think because there are so many things I am trying to think out. Thanks for any ideas, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
RE: mod_perl/passing session information (MVC related, maybe...)
Hi, I don't know this term query hijack can you put it in different words? Thanks, Eric At 03:54 PM 2002-06-12 +0100, you wrote: Do put the user_id into the query session and check it against the user_id in the User session to prevent query hijack
CGI::Application
Hi, I am still working on building a framework, design plan for this busy site I am working on. It is a total revamp so I have the chance to do things right I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I have decided to make my modules class modules instead of traditional modules, and thanks to Perrin's great article, I have a lot more confidence in my basic plan. There are some differences between our site and etoyz. Our site is not nearly as loaded. Busy, but not giant. Still, I would like to build something that can get that big without another total rewrite, moving things around, new hardware sure, but not a whole change to the system. Right now things are small enough that the rewrite will only take a few weeks. So I am looking for gotchas, and other problems that could come esp from CGI::Application because it doesn't make much mention of working under mod_perl. I think the modes could be appealing to the PHP guys in my office. It could give them something to chear about, since I think right now they just look at mod_perl as being more work than PHP which is probably true. I am also sure that the HTML templates will make the boss very happy because he is always changing HTML in scripts and breaking the scripts, then calling and saying, hey the form isn't working anymore! :( The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
At 01:06 PM 6/16/02 -0400, Sam Tregar wrote: On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. Well I was hoping for some 3rd parties :) That is great news! The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam Thanks Sam, It is pretty cool, the more serious work I have to do, the more I appreciate the mod_perl list. I am starting to think that in general mod_perl guys are nice guys :) Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
Hi,
I think mostly it is about having standards and in a business env making it
so that people who only know part of the picture can still work on the
project as a whole. Sounds like OOP huh? HTML in perl scripts just messes
that whole thing up, like I said before, our fearless leader can mess up
stuff now because HTML is in the scripts and he then edits the scripts,
messes *something* up and we have to fix it.(I an new btw just started 3
weeks ago and am cleaning up the mess). Well then, put the HTML in a
module, fine you can do that, but then why not make a system that makes
doing that basic idea easy? And even a system that once you choose to use it
will not get altered and played with by every programer on staff.
I do agree about the CGI pm stuff though. It is goofy to use print header
instead of print content type but still that is getting kind of anal. If it
really matters to your scripts then that would be kind of weird.
Thanks for your thoughts,
Eric
At 01:28 PM 6/16/02 -0400, Dodger wrote:
soapbox
Grr. Why can't people just write bloody applications with HTML in them
instead of spending so much energy tryuing to find a way to avoid writing
any HTML?
I mean, it's not that hard. Formulate what you want parts to do, make a sort
of vanilla, unformatted output here-doc ior template file for each part as
necessary, get the functionality going, then prety it up by copying each
here-doc or template file into Dreamweaver or something, formatting the HTML
to look nice, and then moving the formattted html back in.
Template. Mason. Yecch. I feel mildly nauseated every time I hear about
stuff like Mason and similar cop-outs. If people would spend half the time
learning to output their own HTML that they do trying to find ways around
doing so, they'd get a lot more programs written, and there would be less
ugly, clunky, messy, badly-interfacd, hard-to-use and ungodly slow web
applications out there.
I'm still distastefully amazed when I find people using CGI.pm to print a
content-type header on something that in no other way uses CGI.pm, has no
cookies, or anything else. Yes, I have actually seen someone use CGI to do
nothign more than dump their environment variables, when a simple;
print Content-type:
text/html\n\ndl\n,map(dt$_/dt\ndd$ENV{%_}/dd\n, sort keys
%ENV),/dl\n;
would do the job perfectly fine.
/soapbox
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
duplicate output with Registry.pm
Hi, I know this is a FAQ sort of question, but I can't find it in the faq and I am going nuts. Like I know I know the answer to this, but I just can't get it back in my head. Any output under Registry.pm gets duplicated. One page = two doubled pages. I am using CGI::Application and HTML::Template, but I believe this is a mod_perl problem since it doesn't happen when I use the same scripts in a regular cgi-bin. Also if someone knows where I can find this on the web I would be grateful. I just can't seem to get the keywords right today. Thanks, Eric
Re: duplicate output with Registry.pm
Hi, It happens with the printenv script also. Again, I did this to myself before, but I can't remember how I fixed it. It was something very simple. Thanks, Eric My http.conf perl stuff = # mod_perl config PerlRequire /usr/local/apache/conf/Start.pl PerlFreshRestart On PerlInitHandler Apache::StatINC PerlSetVar StatINC_UndefOnReload On Alias /perl /usr/local/apache/perl PerlWarn On PerlModule Apache::Registry Location /perl PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Alias /perlrun /usr/local/apache/PerlRun Location /perlrun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI /Location http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: duplicate output with Registry.pm
Hi, I will try that out. It was something like that, it even rings a bell a bit. Thanks! I will let you know. Eric At 03:51 PM 7/16/02 +0200, Eric Cholet wrote: --On Tuesday, July 16, 2002 06:44:10 -0400 Eric Frazier [EMAIL PROTECTED] wrote: Hi, It happens with the printenv script also. Again, I did this to myself before, but I can't remember how I fixed it. It was something very simple. Thanks, Seems like Location /perl will happily match urls such as /perlrun. Maybe you want to add trailing slashes to your Location and Alias directives. Eric My http.conf perl stuff = # mod_perl config PerlRequire /usr/local/apache/conf/Start.pl PerlFreshRestart On PerlInitHandler Apache::StatINC PerlSetVar StatINC_UndefOnReload On Alias /perl /usr/local/apache/perl PerlWarn On PerlModule Apache::Registry Location /perl PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Alias /perlrun /usr/local/apache/PerlRun Location /perlrun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI /Location http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant -- Eric Cholet http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
reading an ENV with Perl that was set with mod_rewrite [E= : ]
Hi, Has anyone used mod_rewrite to set an environmental variable based on the result of a reg exp? For example: RewriteRule ^/pt=([^/]+)?(.*) /home/me.com/public_html/$2 [E=PT:$1] I can get a static url like: RewriteRule /perl /usr/local/apache/perl/printenv [E=ERIC:bob] to work, but the first one I can't. PT doesn't exist, but ERIC does. I know this is not exactly on topic, but it is a weird sort of issue, the admin I was dealing with said he could get the above ENV with PHP or mod_perl but not with perl CGI's I can't seem to get it with a mod_perl Registry script either though. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Apache::DBI and CGI::Application with lots of modules.
Hi,
I am glad to see the list traffic has been picking up lately. It makes me
have higher hope about posting this.
First some background info.
I have a fairly large CGI::Application module about 30 run modes that pretty
much follows the example mailform module. I am also using HTML::Template
within the module. I am running on, FreeBSD 4.6 1G mem mysql 4.02 with
Innodb tables.
A typical run mode looks like this.
sub doug_holds {
my $self = shift;
my $q = $self-query();
my $holdtype = $q-param('holdstate');
my $holdsearch = new holds();
$holdsearch-HoldType($holdtype); # set hold type for the query
my $header = parse_header($self);
return $header . $holdsearch-getAllHolds();
}
Of course many of other subs look like this
sub customer_name_search {
my $self = shift;
my $index_page = $self-param('CUSTOMER_NAME_SEARCH_TMPL');
my $output='';
my $tmpl_obj = $self-load_tmpl($index_page,
die_on_bad_params = 0,
cache = 1,
stack_debug =$debug
) or confess(could not create template);
$tmpl_obj-param(base = $self-param('base'));
$tmpl_obj-param(RUNMODE = 'customer_display');
$tmpl_obj-param(USER = $selected_user);
my $header = parse_header($self);
return $header . $tmpl_obj-output;
}
But that isn't relavent to my problem.
In the first sub, I create a new holds instance. Each of these modules like
holds work like this
package Holds;
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
#die $self-{OrdNum}, $self-{HoldReason};
return $self;
}
sub OrdNum {
my $self = shift;
if (_) { $self-{OrdNum} = shift }
return $self-{OrdNum};
}
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
$processed_hnd-execute($self-{OrdNum}) or confess (can't execute
processed);
my ($isprocessed) = $processed_hnd-fetchrow_array;
$processed_hnd-finish();
if ($isprocessed){
$self-{ProcessStatus} = 1;
return #4EEE94;
}else{
$self-{ProcessStatus} = 0;
return FF;
}
}
..
sub db_connect {
require DBI;
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
}
Most of the modules just have simple subs called db_connect that don't have
prepared statments sitting like this. I did this because I have to check the
status of a LOT of rows and return the display fast. This seemed to work
well at the time. It was defiantly faster that preparing the statement over
and over.
I am running under mod perl 1.x Apache 1.3x, and loading my CGI::App module
and other modules from a start.pl
I am using Apache::DBI and connect_on_init. So I have these problems, they
all seem to be related, but how??
1. Connections are getting lost. I get errors in the log about fetch without
an execute which indicate this. Either the user sees an internal server
error, or else I believe DBI will try to reconnect and the query will then
succeed. But that slows things down when it happens. All I have to do to
these kinds of errors is reload a page very quickly. click, click, click fast..
2. Every once in a while I get an out of memory error.
3. My main search result page is getting cached, the closure type of
problem. ***Sometimes*** All I have read says that because I am using oop
modules and use strict along with use vars that should not happen. I have
not gotten any this variable will not stay shared types of warnings.
for this I have tried specificly undefing the display scalars, the result
sets etc. I just can't seem to find out what var is causing the problem, and
I can't find any examples of closures.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin, I am going to read over this closely, thanks for all of the advice! What frustrats me about the search getting cached/closure thing is that I just don't have any global variables that have anything to do at all with the search results. I have read over and over examples with closures, recognize the example you included as one, but I still can't seem to find it in my own code. I guess I need to take a fresh look again. I did -X httpd and it is happening every time. I think part of what is getting me is I have used mod_perl for smaller things, but now it is a pretty big system. I don't seem to be able to get away with as much :) Also, I am really trying to bring my code level up a notch, but as you pointed out, there are some things I am doing that I don't really understand well enough yet. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
if I have this situation, I will get a warning. I am not getting any
warnings, but I am getting this behaviour with my search queries getting stuck
The only thing I do is again, copied from the perltoot
package Searches;
use strict;
use Carp;
use vars qw($dbh);
use gentimeid; # generate time id based
use Calc_Price; # get totals
use warnings;
# use DBIx::XHTML_Table; # maybe later
use QueryPrint;
#use Data::Dumper;
# These searches are restricted to user level searches, there will be a
admin level search for
# managment reports
$dbh = db_connect();
# requires a $q query object to be init.
sub new {
my $self = {};
my $proto = shift;
my $class = ref($proto) || $proto;
$self-{queryobject} = undef;
$self-{isDomestic} = undef;
$self-{isInternational} = undef;
$self-{isShippingSame} = undef;
$self-{CustIsInserted} = undef;
$self-{OrderIsInserted} = undef;
$self-{CustNum} = undef;
$self-{OrderNum} = undef;
bless ($self, $class);
return $self;
}
sub queryobject {
my $self = shift;
if (_) { $self-{queryobject} = shift }
return $self-{queryobject};
}
Other stuff not used yet
sub LookupOrder {
my $self = shift;
my $q = $self-{queryobject};
my $output = '';
my $hasparameter = 0;
... Build a query from CGI.pm vars passed in though queryobject
...
$order_name_qu .= ORDER BY $orderby ; # the query string is here
if ($hasparameter == 1) { # if something was filled in the search form
my $sth = $dbh-prepare($order_name_qu) or confess(Main search
failed $order_name_qu);
$sth-execute() or confess(Main search failed $order_name_qu);
my $headers = $sth-{'NAME'};
my rows= $sth-fetchall_arrayref();
my $resulthtml = new QueryPrint(ResultSet = rows,
Action = 'customer',
ColumnList = $headers);
my $html = $resulthtml-SetAction(); # sets a template type in the
QueryPrint module
$output = $resulthtml-QueryPrint();
$sth-finish();
#warn QUERY - $order_name_qu;
undef rows;
undef $resulthtml;
undef $order_name_qu;
return $output;
} else {
return no query to do;
}
Then this is all called from my CGI::Application module
sub customer_display{
my $self = shift;
my $q = $self-query();
my $customersearch = new Searches();
$customersearch-queryobject($q); # set the query
my $header = parse_header($self);
return $header . $customersearch-LookupCustName();
}
So going nuts now, where is the problem? My QueryPrint module is pretty
much the same, so if this is ok, it should be as well.
Thanks,
Eric
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote: Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? I have checked the above, and I have lots of warns spaced around so I can watch things in the error log. Is the data that you're passing to the template correct? That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Thanks again, Eric Throw in some warn statements. Run it in the debugger if you need to. - Perrin (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do the connect
in the new() vs up top outside of a sub.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them
ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from
orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
I did this, I was a little scared about calling $dbh-finish() but I did
what you said, and yes life is good I don't notice a speed difference.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
I have no idea why I put off doing that for so long. But that is done now as
well.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. Thanks for your advice, I am thinking besides the general advice I have received, Apache::DB will be my next most helpfull item. Eric At 02:33 PM 10/14/02 -0400, William McKee wrote: On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I had to read that over a few times to get it. And now I see that I do indeed have that situation, there are a number of times when I call my $holdstatus = new Holds(); from within a module that also has a new method. What I don't understand is how does my code work at all? Thanks, Eric At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote: On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED] (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: We need help from mod_perl users with technical expertise in non-mainstream OSs
Hi, I have to say that was the nicest rant I have read in some time. I wish I knew something about those other OS's :( Eric At 10:35 AM 12/17/02 +0800, Stas Bekman wrote: Here at the list we have a rather sucky trend in the last year or so. Those folks who report problems that they have on platforms that aren't *BSD, Linux and Win32 mostly get unasnwered. Doug, who seems to know about everything, used to respond to those souls, but nowadays he's too busy with real work. We have plenty of folks who are kind enough to help others with Linux, BSD flavors and Win32. So we are all dandy on these platforms. So, my big request is to all the folks on the other platforms, whose users don't get their problems resolved here. If somebody posts a problem that happens on the platform that you use, please try to help that person, even if you don't consider yourself an expert. Many times a participation in the person's quest helps him to find the way on its own. What bugs most people is the silence. Also if you know somebody who may know the answer but not on the list, please take the initiative and try to kindly ask that person to help. And who knows may be he will enjoy to help and do that in the future as well. Please, stop lurking in the shades, but try to help when you see that nobody else does. Especially if you were helped here before. Remember that you have to give back, if everybody becomes a leech there will be no blood left. Also remember that helping others is addictive, you just need to start doing that. Also remember that we all do mistakes. And we aren't experts in all fields. So if your answer is incorrect, it's not a big problem, since surprisingly, someone, who ignores the original question in first place, immediately posts to correct you. Don't feel bad about that, since you've just learned something. On the opposite feel good about your follow-up, because you tried to help. So, if my rant wakes anybody out there on SunOS, can you please try to figure out what the problem is with Kenny Smith's report: http://mathforum.org/epigone/modperl/sleikrigroo There are many earlier questions that went unanswered, just go to http://mathforum.org/epigone/modperl and see which posts have no followup, and try to help. It's better late, then never. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [mp2] e-Commerce
Hi, On that note, how about just using Apache2 for the proxy front end, and mod_perl /apache 1.x for the back end? I have wanted to try to avoid the thttpd stuff for images and from what I have heard about apache2 it can handle static pages a lot faster than the 1.x did. Thanks, Eric At 04:07 PM 1/21/03 +1100, Stas Bekman wrote: Ged Haywood wrote: modperl 2 with apache 2 thread is stable enought for start one big project of ecommerce? If it were my decision I'd say not yet, use mod_perl 1.27 with Apache 1.3.27. It depends on your needs. The majority of the features is there and should work just fine. The stability can be ensured only when more people will start using it and see that things are stable. So it's a chicken and egg problem. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [mp2] e-Commerce
Hi, You know I was all ready on my dev box to start messing around with apache2, when we had a major evil thing happen on our fancy server. So my dev box had to become our server. And because I have not had any personal experence with apache 2, I converted everthing back to 1.x on the dev box. But you are right of course, I should not just assume because of hearsay that Apache2 will be faster. But between the threading, and the file cache module I *hope* it is faster :) Here is one kind of old thing I found on google: http://www.zend.com/lists/php-dev/200202/msg01675.html They are focused on PHP, but it seems like there might be some problems with the DSO only stuff. Weird that it is not easier to find stuf, I would have expected millions of hits on google for this. I will definatly will work on a better test with static and mod_perl once we get our fancy server back and post it to the list. But I can't believe someone on this list hasn't done that already. Thanks, Eric At 06:09 PM 1/21/03 +1100, Stas Bekman wrote: Perrin Harkins wrote: Eric Frazier wrote: On that note, how about just using Apache2 for the proxy front end, and mod_perl /apache 1.x for the back end? I have wanted to try to avoid the thttpd stuff for images and from what I have heard about apache2 it can handle static pages a lot faster than the 1.x did. You really should be able to get more than enough performance out of 1.x for static files, unless you are using very old hardware. We used a slim 1.x build with mod_proxy, mod_ssl, and mod_rewrite for all of our static files at eToys and it ran like a champ. It's true that both thttpd and apache 2 have better performance, Where did you see the benchmarks showing that Apache 2.0 has a better performance than 1.3? Apache 2.0 should scale better when threads are used (on platforms where threads are faster than processes) and it's definitely a must for win32, but I haven't seen any numbers other than some reports to the httpd-dev list, so I don't know. Also Apache 2.0 provides features like filters, which were almost impossible with 1.3, though how things get slowed down when these are used is a question. Please notice that I'm not saying that 2.0 is slower, I'm just asking to see the numbers ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket;
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
use Net::hostent;
use Carp;
$|=1;
my $pid;
open (DIED, /var/log/daemon_log) or warn $!;
sub logmsg { print DIED $0 $$: @_ at , scalar localtime, \n }
my $listen_socket = IO::Socket::INET-new(LocalPort = 1081,
LocalAddr = '127.0.0.1',
Proto = 'tcp',
Listen= SOMAXCONN,
Reuse = 1 )
or die can make a tcp server on port 1080 $!;
# make the daemon cross-platform, so exec always calls the script
# itself with the right path, no matter how the script was invoked.
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script;
# POSIX unmasks the sigprocmask properly
my $sigset = POSIX::SigSet-new();
my $action = POSIX::SigAction-new('sigHUP_handler',
$sigset,
POSIX::SA_NODEFER);
my $action_alrm = POSIX::SigAction-new('sigALRM_handler',
$sigset,
POSIX::SA_NODEFER);
POSIX::sigaction(POSIX::SIGHUP, $action);
POSIX::sigaction(POSIX::SIGALRM, $action_alrm);
sub sigHUP_handler {
print got SIGHUP\n;
exec($SELF, @ARGV) or die Couldn't restart: $!\n;
}
sub sigALRM_handler {
print got ALARM timeout\n;
}
$SIG{CHLD} = \REAPER_NEW;
sub REAPER {
$SIG{CHLD} = \REAPER; # loathe sysV
my $waitedpid = wait;
logmsg reaped $waitedpid . ($? ? with exit $? : '');
}
sub REAPER_NEW {
logmsg got - @_\n;
my $wpid = undef;
while ($wpid = waitpid(-1,WNOHANG)0) {
logmsg main $pid -- reaped $wpid . ($? ? with exit $? : '')
;
print DIED reaped $wpid . ($? ? with exit $? : '');
}
}
print PID: $$\n;
print ARGV: @ARGV\n;
print [Server $0 accepting clients]\n;
#while (my $connection = $listen_socket-accept()) {
while (1) {
my $connection = $listen_socket-accept() or do {
next if $!{EINTR};
last;
};
print DIED Erro was $! %! \n;
$connection-autoflush(1); ## missing seemed to cause client problem, but
not telnet
if (!defined($pid = fork)) {
logmsg cannot fork: $!;
}elsif
Re: mod_perl v2 Forking
Hi, That sound like one way to go, I want to be very careful with something like this. You speak as if restoring 5.6 behaviour is the best or only way to go. Do you see any other alternatives? Thanks, Eric At 04:57 PM 9/16/03 +0200, Rafael Garcia-Suarez wrote: Eric Frazier wrote: ... But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I know that there is a change in how signals are handled, they call it deferred signal handling because Perl now is suppose to wait until the Interpeter is in a safe state. As I understand it this might avoid some things like core dumps or other errors related to dieing while trying to do something besides dieing. Mostly, yes. Look at the perldelta manpage that is distributed with perl 5.8.0, section Safe Signals. I did read that, it seems kind of misleading. The 5.8 IPC doc was more helpful, but I still didn't get a clear idea how to handle this and the examples are not updated yet. If you want to restore the 5.6-ish unsafe signal handling, this is not possible with 5.8.0 :(. But, as it has been acknowledged that this unsafe behaviour is desirable in some cases, it will be possible with perl 5.8.1. You can grab a 5.8.1 release candidate 4 from CPAN : http://search.cpan.org/~jhi/ (RC5 should be out in a few days) and see with it if using unsafe signal handlers solves your problem. You can enable them with the PERL_SIGNALS environment variable. Here's the relevant part of the perlrun manpage that comes with perl 5.8.1 RC4 : =item PERL_SIGNALS In Perls 5.8.1 and later. If set to Cunsafe the pre-Perl-5.8.0 signals behaviour (immediate but unsafe) is restored. If set to Csafe the safe (or deferred) signals are used. See Lperlipc/Deferred Signals (Safe signals). HTH. (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
RE: mod_perl v2 Forking
Hi,
Doing this works for me. But I am ending up with some errors that I didn't
have before. Of course my bosses would get mad if I posted all of the code
involed, but basicly a database connection that was working fine is now
returning mysql server has gone away, meaning that the connection got
killed. What is weird/scary, is that if I change your $SIG{CHLD} = 'IGNORE';
back to the handler I was using, the database error goes away, but I am back
were I was. Fun huh? :)
Thanks,
Eric
At 03:57 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
I had a problem with 5.8.1 and forking in that I was either getting zombies
using the 5.6 examples or the parent was dying, depending on which example
was used. The way round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way, then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket;
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
use Net::hostent;
use Carp;
$|=1;
my $pid;
open (DIED, /var/log/daemon_log) or warn $!;
sub logmsg { print DIED $0 $$: @_ at , scalar localtime, \n }
my $listen_socket = IO::Socket::INET-new(LocalPort = 1081,
LocalAddr = '127.0.0.1',
Proto = 'tcp',
Listen= SOMAXCONN,
Reuse = 1 )
or die can make a tcp server on port 1080 $!;
# make the daemon cross-platform, so exec always calls the script
# itself with the right path, no matter how the script was invoked.
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script;
# POSIX unmasks the sigprocmask
RE: mod_perl v2 Forking
Hi,
Well, I am not sure if this is going to be the best solution long term, but
it works!
while ( $connection ){
my $return_value = undef;
if(/quit|exit/i){ last;}
elsif (/closeme/i ) {$connection-close(); }
elsif (/date|time/i){ printf $connection %s\n, scalar
localtime; exit(0); }
that did call to a sub, and then connected to a database. I am wondering if
that connection object is better off being global. I changed the connect to
be global, restarted and did a test and it worked fine! I was all ready to
post back to here with the good news, when just to double check I went back
and made the db connect in the local sub like before. And it still worked?!
So it seems like I might be in better shape for now, but I might have some
long term problems with DB connections dieing, most likely related to this
child handling. I have to think that becase the query I am doing is VERY
well tested and never causes an issue.
Thanks tremedously for everyone's help so far, I at the very least have some
directions to go in now.
I still would very much like to learn what the correct, put it in the book
solution should be..
Eric
At 03:57 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
I had a problem with 5.8.1 and forking in that I was either getting zombies
using the 5.6 examples or the parent was dying, depending on which example
was used. The way round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way, then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket;
use FindBin ();
use File::Basename
RE: mod_perl v2 Forking
:) I think that makes sense. It was created in the child. It seemed to be
fixed when I made the connection global. When I tried the connection in the
child again it might well have been a lucky transpireing of events that let
the child stay alive long enough for the query to get completed. So I should
keep it global I think.
Thanks,
Eric
At 04:24 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
is the database connection created in the child or before it?
If it's created inside the child then it'll die ungracefully when the child
dies, so put something nice and fluffy to close it before the exit.
Otherwise, I don't know I'm afraid.
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:57
To: Stephen Hardisty
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl v2 Forking
Hi,
Doing this works for me. But I am ending up with some errors that I didn't
have before. Of course my bosses would get mad if I posted all of the code
involed, but basicly a database connection that was working fine is now
returning mysql server has gone away, meaning that the connection got
killed. What is weird/scary, is that if I change your $SIG{CHLD} = 'IGNORE';
back to the handler I was using, the database error goes away, but I am back
were I was. Fun huh? :)
Thanks,
Eric
At 03:57 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
I had a problem with 5.8.1 and forking in that I was either getting zombies
using the 5.6 examples or the parent was dying, depending on which example
was used. The way round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way, then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket
