IOL's in APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

Okay, we need to move IOL down to APR, but before we do that, we need to
decide the best way to do this.  It is getting done, but we need to decide
the best way to proceed.  There are two options:

1)  The current solution.  Have a separate IOL type, which you have to
create, and fill out, and then you push the APR type into the IOL, and
continue.

2)  Include the IOL in the APR type.  When you create an APR type, the IOL
will be filled out for you, and you can just continue.

Since option 1 is currently done, I will let people examine the code to
see how it works.

Option 2 requires that we take define the IOL type in a common header
file, and just pass instances of the IOL type to all of the I/O APR type
creation routines.  The type could be typdef'ed for files/sockets/mmap
regions/etc, all pointing to the same IOL type which would look like:

_IOL_
void *
(*read)
(*write)
(*close)
etc.

(Another variation follows at the end of this note).  Because this owuld
not be an incomplete type, functions could easily be called the same way
we call IOL functions now.  The biggest difference is that we do not have
to create an IOL type and push stuff into it, all of that ugliness is done
for us.

This obviously leads into a discussion of the "correct" way to implement
layering (for a version after 2.0).  There are basically two options
again: 

[ This is all provided as food for thought, to be used when making a
decision of the above issues.  I would rather not get into a heated debate
over the right way to do this, because it is most likely not going to end
up in 2.0 anyway.  However, it is a useful discussion, and it gets us
thinking along the right lines. ]
 
1)  Linked lists of IOL variables.
2)  One IOL variable with linked lists for the individual functions.

Option 1 would look like:

fields      Base IOL       CGI IOL    SSI IOL   Speling IOL
void *      ap_socket_t    NULL	      NULL      NULL
(*read)     ap_read        NULL       NULL      NULL
(*write)    ap_write       cgi_write  ssi_write speling_write
(*close)    ap_close_sock  NULL       NULL      NULL
etc.

We don't want to fill in the void* for anything other than the Base
communications IOL, because it will just confuse things.  We definately
don't want to have more than one function for each IOL after the Base one.

Option 2 would look like:

fields      Base IOL       
void *      ap_socket_t -> NULL
(*read)     ap_read     -> NULL
(*write)    ap_write    -> cgi_write -> ssi_write -> speling_write
(*close)    ap_close_sock ->  NULL 
etc.

I think this is self explanitory.

I began this note liking option 2, now I'm not so sure.  Neither one is
really bad, we just need a decision.

I am envisioning that the handler and post_read phases of the modules
would disappear, and be replaced by two filter functions, one for reading
and one for writing.  Those phases would be pushed onto the IOL where we
are currently calling the individual phases.  And they would be called
just after we read the data, or just before we wrote the data.

I am also envisioning two helpers functions, ap_push_iol and ap_pop_iol
( modified to ap_push_iol_read/write/etc and ap_pop_iol_read/write/etc in
the case of option2) which would add these functions to the IOL list.



The promised variation on the APR types.  ALL APR types have a context
associated with them.  Currently, it is not possible to retreive that
context.  It would be possible to put the context into the same type as
the IOL functions, and the context would then be easily accessible.
Example:

_IOL_
ap_context_t *
void *
(*read)
(*write)
(*close)
etc.

This would allow people to scope data the same as the APR type they got
the context from.  For example, if I know I have a peice of data that is
alive only as long as a particular file, I can grab the context from that
file and allocate data out of the context.

Thoughts?

Ryan
_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: IOL's in APR.

[Manoj Kasichainula <ma...@io.com>]

Option 2 is basically an interface change from option 1; there's no
real added code bloat, just a couple of added function pointers stored
in the type, so it's okay.

But:

Option 3:
It would be less work, just as clean, and slightly more functional to
just throw the current IOL code in APR, and just add new constructor
functions that create the file and push it into the IOL for us. This
is Option 2 to the outside world, with option 1 implemented
underneath.

There is one minor advantage of doing this, which is that if a
function can only handle raw files and not sockets filtered by
buffering filtered through SSI, then the function can "enforce" this
by specify (ap_file_t *) in it's declaration.

On Wed, Nov 10, 1999 at 03:24:28PM -0500, Ryan Bloom wrote:
> The promised variation on the APR types.  ALL APR types have a context
> associated with them.  Currently, it is not possible to retreive that
> context.  It would be possible to put the context into the same type as
> the IOL functions, and the context would then be easily accessible.

I've don't like this very much. It puts a context into the IOL API,
meaning that every IOL must have a context defined, even if there's no
particularly good reason to give it one. And, it will get used as a
out-of-bad channel for information, which I think this is a great way
to obfuscate how a program works for new participants.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/

Apache 1.3 fails to serve pages.

[Jeff Johnson <je...@websitefactory.net>]

I have an Apache 1.3.x setup (tested against 1.3.9 -> 1.3.10-dev), which exhibits
this behavior.  I've done my best to track it down, and this is the best I can
come up with:

Our Apache configuration is rather complex.  We are running 1.3.10-dev currently,
with Apache JServ 1.1b3, mod_ssl/2.4.9-snap, PHP/4.0B3-RC4, mod_fastcgi/2.2.2,
mod_macro/1.1.1, mod_perl/1.21, mod_frontpage/3.0.4.3-4.0, mod_allowdev/1.5,
mod_sxnet/1.2.4, mod_ecash, mod_DAV 0.9.12, mod_cgiSock/1.1, mod_format/0.3.1,
mod_eaccess/2.2.1.2, mod_cvs/0.4, and the standard Apache stuff, all as DSO's.

I first ran into the problem when when we reached about 1,200 customers, some of 
whom have SSL.  The server would start and startssl, however, when running with
startssl, it would not respond to any requests.  Browsers were able to contact
the host, but not able to send or receive any data.  FD's shouldn't be a problem.
Apache is compiled with FD_SETSIZE of 8192, and the OS should handle 10240 FD's
per process, 13888 or so system wide, using FreeBSD 3.3-STABLE.

We have automatic account creation for our webhosting customers, and we didn't
notice problems until the server was actually stop'd and then started.

To make the long diagnosis short, here is whats going on:

If you have two "Port" directives, it won't serve.  One Port directive, it will 
serve.  It doesn't matter if every module isn't loaded or if SSL is there or not.

Now, if you have > ~1200 customers and stop and start or startssl, the server
doesn't serve.  If you have, say, 900 customers VirtualHost entries and then
start or startssl it works fine.  Then if you add the other 300 or 400 while the
server is running and graceful the server, it works fine, all the new vhosts too!!!

So what we have to do to start Apache is start it without using an Include directive
that initializes the VirtualHosts.  Then, after Apache starts, using an IfDefine,
Include the vhosts.conf file which contains all of the hosts.  This is the only
way it will start and serve pages without either giving FD errors or just crapping
out and not serving at all.

Currently, mod_vhost_alias isn't an alternative due to SSL and other such things,
including some unresolved problems with the (horrid) FrontPage extensions.  Can anyone
give me any suggestions to avoid this horrible kludge and get my life back to normal?

Thanks!!!!