Re: Managing to kill httpd (why?)
At 10.41 -0700 10/13/2000, Doug MacEachern wrote:
On Fri, 13 Oct 2000, Doug MacEachern wrote:
On Sat, 30 Sep 2000, Yann Ramin wrote:
#0 0x80a2605 in ap_table_get ()
#1 0x808961e in XS_Apache__Table_FETCH ()
package Magrathea::WebAPI;
...
my $driver;
you cannot cache data that is tied to $r (e.g., notes table), because
the $r-pool is cleared after each request. string values are ok, but not
objects such as Apache::Table objects which are tied to the r-pool.
just to be clear on this: it's ok to cache things such as Apache::Table
for the lifetime of a request (example, between request phases), but once
the request is over (and r-pool is cleared), such a cache needs to be
flushed.
On a related topic, a great way to make your life miserable is to cache the Apache
request object in the instance data of an "application object" you wish to stick on
$r-pnotes in order to scope it to the request. Makes a nice leak when your request
finishes -- $r goes out of scope to the request lowering the refcount by 1 -- but the
refcount doesn't drop to 0 because $r-pnotes('APPOBJECT')-{'r'} still holds a
reference to it.
(Solution? $r-register_cleanup(sub { $r-pnotes(APPOBJECT = undef) };))
(Yes, I learned that the hard way. :-)
--
David Pisoni -- [EMAIL PROTECTED]
Cnation -- http://www.cnation.com/
310/228-6900 -- 310/228-6905 (fax)
"One machine can do the work of fifty ordinary men. No machine can do the work of one
extraordinary man." -Elbert Hubbard, author, editor, printer (1856-1915)
Re: bytes_sent - bytes_received?
Title: Re: bytes_sent -
bytes_received?
At 7.25 PM +0100 10/7/2000, Matthew Byng-Maddick wrote:
On Sat, 7 Oct 2000, Drew Degentesh
wrote:
In addition to the number of bytes sent to the client, Id like
to log how
many bytes are sent *by* the client (the size of the request +
posts , etc.)
Fair enough
I was guessing/hoping that length( scalar( $r-content ) )
would do it, but
earlier in my application (before the log phase) I use
Apache::Request to
(potentially) process a file upload, and Im guessing that clears
out
$r-content.
I'm not sure if it does or not. Anyhow, $r-content won't get you
the full
request, plus all the headers. The best way to do this would be to
put
your measuring code in as a URI Translation handler (with whatever
method
works erm...) and then put the value in a notes field which you
can
then recover later on in the processing.
Any ideas?
Not very helpful, I'm afraid.
MBM
--
perl -e
'$_=unpackb196,packH50,cafa9c0e0abbdf7474590e8296e56c103a3c.
5e97e52e104821;while(m(^.{7})){$a.=$.0;$_=$'''}print
packb224,$a'
Well, if you need the length of the POST data, then you should
be able (assuming the browser follows the RFCs) to get it from
$r-header_in( 'Content-length' ).
If you need the length of the ENTIRE request, theoretically you
could get it by adding together :
1) the above value
CODEmy $headerlength = $r-header_in(
'Content-length' )/CODE
2) the lengths of all the header lines
CODE
my $headers = $r-headers_in();
map { $headerlength += length($_) +
length($headers-{$_}) + 2 }
## +2 above for ': ' between the header key and
value
keys %$headers;
/CODE
3) and the request line
CODE$headerlength += length( $r-the_request()
)/CODE
Did I miss anything? Methinks this is the lot, but I'm
just typing here -- I didn't test it. ;-)
Enjoy,
--
David Pisoni -- [EMAIL PROTECTED]
Cnation --
http://www.cnation.com/
310/228-6900 -- 310/228-6905 (fax)
One machine can do the work of fifty ordinary men. No machine
can do the work of one extraordinary man. -Elbert Hubbard,
author, editor, printer (1856-1915)
RE: CyberCash and mod_perl Experiences
At 11.28 -0400 10/2/2000, Ryan Adams wrote: SNIP Thanks everyone for listening to me rant. I'll keep you posted on what I come up with. I'm toying with the idea of writing an CyberCash module for the Business::OnlinePayment interface. Anyone have any idea where to start? RYAN Actually, we wrote a module (we called it Business::Payment) which supported different payment systems in a DBIish way. (We wrote a Business::Payment::CyberCash, and a Business::Payment::CyberSource.) Unfortunately, we never considered CPANing the code, because I think that because it uses knowledge (e.g., the published API) of these payment systems, public release would violate the license agreements of their payment libraries. Furthermore, the systems were just different enough that we had to strip down the use of functionality in order to write Business::Payment code that was cross-platform (between the payment systems.) I haven't looked at the licenses for these systems for awhile -- does anyone know if they have changed significantly enough to allow for the release of a module such as this? Enjoy, -- David Pisoni -- [EMAIL PROTECTED] Cnation -- http://www.cnation.com/ 310/228-6900 -- 310/228-6905 (fax) "What is to give light must endure burning." - Viktor Frankl, author, neurologist and psychiatrist, Holocaust survivor (1905-1997)
Re: recursion in Apache::Constants::AUTOLOAD?
Sorry I don't have much in the way of details, but we had this problem several months
ago (probably in a previous version of mod_perl), but it silently went away.
(I'm reminded of it because recently I was reviewing the handler() of our recently
open-sourced embedded parser, Apache::XPP, and found that the constants had been
hard-coded to avoid the AUTOLOAD() spinning. I put the constant calls back in :-)
Enjoy,
David
At 8.17 -0700 9/28/2000, Doug MacEachern wrote:
On Mon, 26 Jun 2000, Jim Winstead wrote:
We were seeing some servers spin out of control (allocating memory
slowly) in Apace::Constants::AUTOLOAD (which apparently has been
reported in the mailing list before).
The attached patch fixes the problems for us. Could someone who
understands what is going on here shed some light?
i still don't understand how __AUTOLOAD can be undefined inside the
server. this patch adds an extra check that will prevent recursion if
__AUTOLOAD is somehow undefined and print a stacktrace to give some idea
where the problem is.
Index: Constants/Constants.pm
===
RCS file: /home/cvs/modperl/Constants/Constants.pm,v
retrieving revision 1.20
diff -u -r1.20 Constants.pm
--- Constants/Constants.pm 2000/03/03 20:42:01 1.20
+++ Constants/Constants.pm 2000/09/28 15:12:36
@@ -17,9 +17,16 @@
if ($ENV{MOD_PERL}) {
#outside of mod_perl this will recurse looking for __AUTOLOAD, grr
*AUTOLOAD = sub {
- #why must we stringify first???
- __AUTOLOAD() if "$Apache::Constants::AUTOLOAD";
- goto $Apache::Constants::AUTOLOAD;
+if (defined __AUTOLOAD) { #make extra sure we don't recurse
+#why must we stringify first???
+__AUTOLOAD() if "$Apache::Constants::AUTOLOAD";
+goto $Apache::Constants::AUTOLOAD;
+}
+else {
+require Carp;
+Carp::confess("__AUTOLOAD is undefined, ",
+ "trying to AUTOLOAD $Apache::Constants::AUTOLOAD");
+}
};
}
Re: Scheduling an Apache child for termination/influenceMaxRequestsPerChild counter
At 18.56 +0200 9/26/2000, Ime Smits wrote: Hi, I wonder if it's possible to somehow alter Apache's internal counter matched against MaxRequestPerChild or schedule the launching of a new child from withing mod_perl. The reason I want to do this, is that in the administrator section of my website, quite some stuff gets cached from the PostgreSQL backend on a per process basis and there is really no use to keep all those caches after the administrator hit the logout button. Plus, I want to be able to terminate a process if some kind cache inconsistency is detected. I know it's better to track the origin of that inconsistency and fix it there, but I'm using some modules which I did not create myself and I'm not planning to dig into 5000+ lines of code I did not wrote. What I really would like to do is to just finish the current page, dropping a line like "things are getting fishy here", wipe the administrator's session cookie and let the child die. Ime Can you run the administrative section of your site in a separate server process? That way, you can tune your MaxClients and MaxRequestsPerChild levels very low for that server, while preventing your front-end server from allocating excessive chunks of RAM (and leaving the afformentioned settings optimized.) Enjoy, -- David Pisoni -- [EMAIL PROTECTED] Cnation -- http://www.cnation.com/ 310/228-6900 -- 310/228-6905 (fax) "The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth." -Niels Bohr, physicist (1885-1962)
Re: question: using Apache for non-HTML messages
Really all you need to do is send your response back like you would any response, just without the HTML formatting. If you wanted to be a bit more "correct", you could change the content-type of the respose so that it is not 'text/html'. (In your case, you might just make one up like 'application/x-brians-spiffy-protocol' or whatever you think is appropriate preceded with 'x-'.) Or, if you wanted to debug it using a web browser, you could simply use 'text/plain', and your browser will display the raw result. It is important to note that Apache is an HTTP server, not an "HTML server". It is capable of serving any sort of serial content. So anyway, since it looks like you're using a registry script, you would merely start your output with : print "Content-type: " . $my_content_type . "\n\n"; # note the 2 newlines! and then proceed directly to your proprietary output. Make sense? David At 9.21 -0400 9/25/2000, B. Burke wrote: Here is an example of what I'm looking to do. GET /perl/app.pl?MODE=searchCITY=DallasSTATE=TXID=195302 HTTP/1.0 Accept: text/html User-Agent: MyTestClient1.0 From: nowhere.com I want to replace the HTML request above with something like this: |MODE=search|CITY=Dallas|STATE=TX|ID=195302| I can hard code the handler to do GET's against only one script. The request format is VERY similiar to the arguments in a GET (all I really have to do is translate the pipe). I think for the response, all I need to do is remove the headers entirely, and I can format the script output to conform to our API (I don't need protocol headers for requests nor for responses). I've been able to basically remove the response headers by removing the functionality of ap_sen_header_field() before compiling Apache, but it would be nice to have a more eloquent solution through mod_perl. Thanks, Brian Matt Sergeant wrote: On Mon, 25 Sep 2000, B. Burke wrote: I'm using Apache/1.3.11 with mod_perl/1.22 on an AIX platform to serve as an application server, with persistent ties into a MySQL database. My company is using an in-house socket API for data transfers. The request messages in our API are somewhat similiar to an HTML GET request, in that we use tagged, delimited fields (pipe delimited instead of delimited). I have written a socket server gateway to act as a protocol converter, to convert our API's requests into HTML GET's (and also convert the HTML output into our API's response format). My question is this. Is it possible using mod_perl for me to incorporate the protocol conversion into Apache itself? In other words, can I strip out the need for HTML headers, and rewrite the format of GET requests to comply with our proprietary API? I don't know if this is something that I can do through mod_perl, or if I will have to dig deeper into C and recompile a new server. Any help or ideas will be mucho appreciated! I don't think you'll actually have to re-write anything. Although an example of a transaction would be most helpful. All you have to do is setup mod_perl to handle the connection, Apache _should_ be able to handle the request if it looks enough like a GET request, and you should be able to respond to it with little enough information, provided your responses are also similar to HTTP responses (HTTP response code followed optionally by headers then the body). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
