This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Oscar Serrano <oserra@fondos.net> From: Ged Haywood <ged@www2.jubileegroup.co.uk> Subject: Re: weird problem. Lost of the POST data Date: Wed, 16 Jan 2002 22:30:01 +0000 (GMT) Hi Oscar, On Wed, 16 Jan 2002, Oscar Serrano wrote: > So, one mod_perl CGi can cache several modules and several mod_perl cgis? It's not really a "mod_perl CGI", it's an Apache child process with its own built-in (persistent) Perl interpreter. In that sense it's an ordinary copy of the Perl interpreter which can load whatever Perl modules you have the memory for. The child sits around waiting for something to do. You give it something to do by handing a request to Apache (usually from a browser) which may or may not be configured to cause the Perl interpreter to do something with it. If it does something with the request it may change things inside the memory pages of that child's Perl interpreter which aren't changed in the interpreters of any of the other apache children. > Apache::Registry which I'm interested in. Apache::Registry provides the Apache+mod_perl process with an environment similar to what you see when you use mod_cgi in an ordinary (non-mod_perl) process. But it's only similar, it's not identical. There are all sorts of things (mentioned in the Guide) that you have to look out for, mostly because it's only similar and because the Perl interpreter is persistent. There are alternatives to Apache::Registry which might be better for you, but none provides an exact replica of the CGI environment. > So the maximum size the httpd can grow is the size of all modules and > mod_perl cgis cached in memory. Am I right? Not quite, there are reasons for example why the child might grow without bound. It's covered in the Guide in great detail, including methods of calculating the process sizes and ways of dealing with any processes which misbehave. > print "Content-type: text/html\nPragma: no-cache\n\n"; > $query=new CGI; > $in=$query->Vars(); > > Now I have everything in $in. To be sure of it, why not print everything in $in to the error_log or something like that? (There's a whole chapter on debugging techniques in the Guide. :) > 501 Apache Error? In a properly written program, the ideal would be that no request could cause a server error. I suspect that there's something wrong with the way your code handles the request or (less likely) there's something wrong with the build of the server. === From: "Oscar Serrano" <oserra@fondos.net> To: <modperl@apache.org> Subject: RE: weird problem. Lost of the POST data Date: Thu, 17 Jan 2002 00:52:02 +0100 > -----Mensaje original----- > De: Perrin Harkins [mailto:perrin@elem.com] > Enviado el: jueves, 17 de enero de 2002 0:06 > Para: modperl@apache.org; Oscar Serrano > Asunto: Re: weird problem. Lost of the POST data > > > > There is something that may give a clue. When I restart apache, it takes > > some minutes to throw the first error. But the error get more and more > > frecuently. But not always I get the error. It seems as if some httpd > child > > get corrupted and then, when one of those corrupted childs processes a > > request, it throws this error. > > I've seen that sort of thing before. A common cause of this is > opening some > resource before the fork that shouldn't be shared across processes, like a > file handle or a socket. Check for that. Also, are you using any cleanup > handlers? Do you have any in-house code that uses XS to call C libraries? Ummm yes... you know, I'm using the Template Toolkit. It seems as if the httpd child executes the processing of the template so fast that CGI.pm has no time to get the POST data. I has no sense, because the script, the first thing it does is the $in=$query->Vars(), and the last thing it does is to process a template. But it seems as if it could process the template before getting the POST data. And that would explain why the POST data is mantained in STDIN and then appears concatenated to the very next request: a .gif file the template calls. But I repeat, it has no sense the script processing the template before reading the POST data :-? I'm not using any cleanup handlers. Somebody suggested me to use one to destroy CGI.pm data. But, the true is that the problem is CGI.pm I'll kick CGI.pm away because I only use it to get the variables from a GET or POST data. Thank you very much. === From: "Perrin Harkins" <perrin@elem.com> To: "Oscar Serrano" <oserra@fondos.net>, <modperl@apache.org> Subject: Re: weird problem. Lost of the POST data Date: Wed, 16 Jan 2002 19:01:10 -0500 > Ummm yes... you know, I'm using the Template Toolkit. Try using the Perl stash instead of the XS stash, and see if your problem goes away. > It seems as if the > httpd child executes the processing of the template so fast that CGI.pm has > no time to get the POST data. I don't think so. It seems to me like your processes are getting corrupted by some C code or an improperly shared file handle or socket. I doubt this has anything to do with CGI.pm, since so many people use it and don't report having the same problem. If you want to experiment, you could replace CGI.pm and see if it improves thing for you. There are plenty of other modules you can use to parse POST data. === From: "Perrin Harkins" <perrin@elem.com> To: "Oscar Serrano" <oserra@fondos.net>, <modperl@apache.org> Subject: Re: weird problem. Lost of the POST data Date: Wed, 16 Jan 2002 19:39:00 -0500 > Well all my modules are written in Perl. When you say some C code you mean > the C code in DBI, or CGI or Template, don't you? Yes. That's why I suggest trying Template with the Perl stash instead of the XS one. ===