Re: Managing to kill httpd (why?)

[David Alan Pisoni]

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 -- 
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?

[David Alan Pisoni]

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
'$_=unpack"b196",pack"H50","cafa9c0e0abbdf7474590e8296e56c103a3c".
"5e97e52e104821";while(m(^.{7})){$a.=$&."0";$_=$'"'"'}print
pack"b224",$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
my $headerlength = $r->header_in(
'Content-length' )

2) the lengths of all the header lines

my $headers = $r->headers_in();
map { $headerlength += length($_) +
length($headers->{$_}) + 2 }
   
##  +2 above for ': ' between the header key and
value
   
keys %$headers;


3) and the request line
$headerlength += length( $r->the_request()
)

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 --

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

[David Alan Pisoni]

At 11.28 -0400 10/2/2000, Ryan Adams wrote:


>
>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 -- 
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?

[David Alan Pisoni]

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

[David Alan Pisoni]

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 -- 
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

[David Alan Pisoni]

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=search&CITY=Dallas&STATE=TX&ID=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).
>>
>> --
>> 
>>
>> 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

Re: [ANNOUNCE] BingoX 1.91 (new package)

[David Alan Pisoni]

At 14.50 -0500 9/22/2000, Dave Rolsky wrote:
>On Fri, 22 Sep 2000, David Alan Pisoni wrote:
>
>> The URL
>>  <http://opensource.cnation.com/downloads/BingoX-current.tar.gz>
>>
>> has entered CPAN as
>>   file: $CPAN/authors/id/C/CN/CNATION/BingoX-1.91.tar.gz
>>   size: 72136 bytes
>>md5: cbf5108d666a83b64843e991eea61d1d
>>
>>
>> BingoX is an open source, object oriented Web Application Framework written in 
>mod_perl meant to dramatically reduce the time required to build large dynamic, 
>database driven web sites and applications. BingoX is also a methodology for building 
>web sites and applications which enables groups of developers to work together in a 
>more consistent manner. With the BingoX framework, it is possible with a minimal 
>amount of code to:
>>
>>  * Create large, database driven, dynamic sites in a fraction of the time.
>>  * Access complex relational databases through an intuitive and consistent 
>object-oriented API.
>
>Wow, this portion (BingoX::Carbon) seems largely identical to a subset of
>what my Alzabo project does (alzabo.sourceforge.net).  Before you guys go
>further, you might want to take a look at it.  There are some things
>BingoX appears to do that Alzabo has yet to get to but there's a lot in
>the other direction too.  Plus dare I say that Alzabo is a lot cleaner?  I
>dare.

Interesting.  BingoX::Carbon is actually the most mature portion of BingoX (that is, 
we've been developing it the longest), and it's also the part which stands to change 
the most dramatically in the next version of BingoX (which is already under 
development.)  This development should certainly be informed by Alzabo (and by the 
POOP list) -- we will look into this thoroughly.

Please note that this is by no means the primary function of BingoX -- database 
abstraction is merely a part (though an integral one) of web application development.

>Anyways, this is already OT so you might want to join the POOP list
>(poop.sourceforge.net) for further discussion.

Actually, that page doesn't seem that very interesting.  Can you give me more 
information on the POOP list please (privately, as we are already OT enough :-)

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)

[ANNOUNCE] BingoX 1.91 (new package)

[David Alan Pisoni]

Cnation is pleased to announce the initial posting of BingoX to CPAN.

The URL


has entered CPAN as
  file: $CPAN/authors/id/C/CN/CNATION/BingoX-1.91.tar.gz
  size: 72136 bytes
   md5: cbf5108d666a83b64843e991eea61d1d


BingoX is an open source, object oriented Web Application Framework written in 
mod_perl meant to dramatically reduce the time required to build large dynamic, 
database driven web sites and applications. BingoX is also a methodology for building 
web sites and applications which enables groups of developers to work together in a 
more consistent manner. With the BingoX framework, it is possible with a minimal 
amount of code to: 

* Create large, database driven, dynamic sites in a fraction of the time. 
* Access complex relational databases through an intuitive and consistent 
object-oriented API. 
* Create powerful administrative interfaces for managing content in your 
database. 
* Create dynamic web sites which separate business logic from code, letting 
HTML Integrators work on display while Application Programmers write business logic. 
* Reuse code within a project and between projects, cutting development time 
even further. 


What BingoX is not :
* A new form of gambling.
* A domestic or farm animal.

For more detailed information on BingoX (and other Cnation open source projects) go to 
.


-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- 
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)