porting from IIS

["Harold J. Ship" <Ha...@giant-steps-networks.com>]

Hi
 
This is my first post to this list. I have a project coming up for a
customer who wants to get their IIS extension working as an Apache
module on Linux.
 
Some of the challenges are:
 
1) They maintain their own thread pool and scheduler. Those threads
process requests and send responses back to the user agent. This frees
up IIS threads. Is this possible to do in Apache? By the way, they use
Extension Control Blocks to do that.
 
2) Some requests have "sub-requests" that are sent back through IIS. The
main request maintains some globally accessible data that the
sub-requests write to. When the sub-requests are completed, the main
request can use that data. Is this kind of thing possible in an Apache
module?
 
Thanks,
Harold Ship
Giant Steps Networks Ltd

Re: Send mail with Apache

[Samuel Gomez <e6...@est.fib.upc.edu>]

Thanks ed.

You realized of the kind of help I need.

In APR docs is explained how to use pipes and as you said, I can try to 
use a mail transfer agent. Sounds quite possible.

(I'm quite noob with C and the sort of solutions it allows to achieve, 
as you saw.)

Samuel



ed wrote:
> On Fri, 04 Jul 2008 18:42:48 +0200
> Samuel Gomez <e6...@est.fib.upc.edu> wrote:
>
>   
>> Is there any way of sending e-mail with Apache?
>>
>> For example, how are mails sent when the ServerAdmin directive ( 
>> http://httpd.apache.org/docs/2.0/mod/core.html#serveradmin ) is used?
>>
>> I was looking around the code but I wasn't able to find when this
>> data is used to compose and send a mail.
>>     
>
> Well, with Apache itself, I don't think there's a routine, since mail
> is implemented differently on different platforms.
>
> I cannot think of a method to deliver mail on a Windows system, mainly
> because it's not got that orientation, first one has to buy exchange ...
>
> Anyway, probably the most likely method is to open a pipe
> to /usr/lib/sendmail or /usr/sbin/sendmail, whatever your religion,
> then write mail to it.
>
>   

Re: Send mail with Apache

[ed <ed...@s5h.net>]

On Fri, 04 Jul 2008 18:42:48 +0200
Samuel Gomez <e6...@est.fib.upc.edu> wrote:

> Is there any way of sending e-mail with Apache?
> 
> For example, how are mails sent when the ServerAdmin directive ( 
> http://httpd.apache.org/docs/2.0/mod/core.html#serveradmin ) is used?
> 
> I was looking around the code but I wasn't able to find when this
> data is used to compose and send a mail.

Well, with Apache itself, I don't think there's a routine, since mail
is implemented differently on different platforms.

I cannot think of a method to deliver mail on a Windows system, mainly
because it's not got that orientation, first one has to buy exchange ...

Anyway, probably the most likely method is to open a pipe
to /usr/lib/sendmail or /usr/sbin/sendmail, whatever your religion,
then write mail to it.

Re: Send mail with Apache

[ed <ed...@s5h.net>]

On Fri, 04 Jul 2008 20:18:55 +0200
Samuel Gomez <e6...@est.fib.upc.edu> wrote:

> Before opening a TCP connection to the smtp port of the remote server 
> and start to cry, I think I will try the solution suggested by ed.

Well, if you do this, you will be relying on network over heads which
could make the user experience very poor (they will be waiting for you
to deliver mail, maybe the receiving server will scan the mail for
viruses etc before the user gets their page to load)...

Re: Send mail with Apache

[Samuel Gomez <e6...@est.fib.upc.edu>]

Thanks Mads.

I just reviewed the functions provided by APR and APR-utils and didn't 
notice any friendly way of sending mail.

Before opening a TCP connection to the smtp port of the remote server 
and start to cry, I think I will try the solution suggested by ed.

Samuel



Mads Toftum wrote:
> On Fri, Jul 04, 2008 at 06:42:48PM +0200, Samuel Gomez wrote:
>   
>> For example, how are mails sent when the ServerAdmin directive ( 
>> http://httpd.apache.org/docs/2.0/mod/core.html#serveradmin ) is used?
>>
>> I was looking around the code but I wasn't able to find when this data is 
>> used to compose and send a mail.
>>
>>     
> That's because it isn't used to send mail. It is merely for
> informational display on error pages.
>
> vh
>
> Mads Toftum
>   

Re: Send mail with Apache

[Mads Toftum <ma...@toftum.dk>]

On Fri, Jul 04, 2008 at 06:42:48PM +0200, Samuel Gomez wrote:
> For example, how are mails sent when the ServerAdmin directive ( 
> http://httpd.apache.org/docs/2.0/mod/core.html#serveradmin ) is used?
>
> I was looking around the code but I wasn't able to find when this data is 
> used to compose and send a mail.
>
That's because it isn't used to send mail. It is merely for
informational display on error pages.

vh

Mads Toftum
-- 
http://soulfood.dk

Send mail with Apache

[Samuel Gomez <e6...@est.fib.upc.edu>]

Hello all.

Is there any way of sending e-mail with Apache?

For example, how are mails sent when the ServerAdmin directive ( 
http://httpd.apache.org/docs/2.0/mod/core.html#serveradmin ) is used?

I was looking around the code but I wasn't able to find when this data 
is used to compose and send a mail.

Thank you.

Samuel

Re: porting from IIS

[Rainer Jung <ra...@kippdata.de>]

Nick Kew wrote:
> On Fri, 25 Jul 2008 11:06:44 +0300
> "Harold J. Ship" <Ha...@giant-steps-networks.com> wrote:
> 
>>> That, on the other hand, sounds like solving a problem that isn't
>> there.  Unless you really need 
>>> priority queues, you can just let everything run in parallel.
>> Well, even a priority queue isn't enough. Suppose there are N threads
>> for handling requests. If N+M "heavy" requests come in a burst, then
>> there won't be any way to handle any "light" requests until at least
>> M+1 "heavy" requests are completed. This would be the same even with a
>> priority queue.
> 
> The Event MPM decouples threads and requests (though it's dealing
> with a different issue) ...
> 
> I still don't see what you have in mind.  If your "heavy jobs" are
> being submitted to a batch processing queue, why not say so?
> But if they're being processed within the HTTP transaction,
> then you're just describing an overloaded server that needs to
> limit its load in some way (e.g. absolute number of 'heavies')
> and return 503 to clients above that limit.  See for example
> mod_load_average.

It sounds like they want to have different thread pools for light or 
heavy requests in order to enclose exhaustion problems within those 
pools. E.g. to many heavy requests should not block handling of light 
requests. Of course exhaustion of one of those pools would still make 
problems for the requests of the same type.

Think of a not so important report generation feature, that uses long 
running requests and more important throughput features using short 
running requests. If something gets stuck in the reporting feature, it 
will exhaust the threads and block further throughput requests.

I can imagine cases, were the problem ist not only theoretic and a 
separation of the pools is arguable in order to limit possible damage 
(although it increases overall complexity and you'll need more overall 
threads than with a single pool).

If you put a reverse proxy in front and use different backend thread 
pools, then the reverse proxy could timeout for heavy requests when the 
backend thread pool is exhausted (needs to use a short connect timeout) 
and would therefore not get starved itself.

The backends could either be httpd instances or other things (Tomcat 
with separate connectors etc.).

Another possibility would be to check the number of httpd threads 
working on heavy requests when a new heavy one comes (via the 
scoreboard) in and declining the request when a limit is reached. That 
would only be OK, if heavy requests are usually rare, so the performance 
overhead would not be to much.

Regards,

Rainer

Re: porting from IIS

[Nick Kew <ni...@webthing.com>]

On Fri, 25 Jul 2008 11:06:44 +0300
"Harold J. Ship" <Ha...@giant-steps-networks.com> wrote:

> > That, on the other hand, sounds like solving a problem that isn't
> there.  Unless you really need 
> > priority queues, you can just let everything run in parallel.
> 
> Well, even a priority queue isn't enough. Suppose there are N threads
> for handling requests. If N+M "heavy" requests come in a burst, then
> there won't be any way to handle any "light" requests until at least
> M+1 "heavy" requests are completed. This would be the same even with a
> priority queue.

The Event MPM decouples threads and requests (though it's dealing
with a different issue) ...

I still don't see what you have in mind.  If your "heavy jobs" are
being submitted to a batch processing queue, why not say so?
But if they're being processed within the HTTP transaction,
then you're just describing an overloaded server that needs to
limit its load in some way (e.g. absolute number of 'heavies')
and return 503 to clients above that limit.  See for example
mod_load_average.

> > So that's a (reverse) proxy architecture.  Apache is happy with
> > that,
> and indeed it's a very common scenario.
> 
> Not exactly a reverse proxy in the usual sense because the other
> server is not a web server. In fact in windows it's another process
> connected using COM. We will probably wrap it with a web interface as
> an interim solution until the other process can also be ported to
> Linux.

OK, communicating with a backend using COM is a job for a module,
which could be a mod_proxy protocol module.  You might want to look 
at how mod_proxy(_balancer) and mod_dbd maintain connection pools.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

RE: porting from IIS

["Harold J. Ship" <Ha...@giant-steps-networks.com>]

One correction: the N+M example would not be exactly the same for a
priority queue. Only one of the heavy requests would have to be
completed for the priority queue. However, this could be on the order of
30s in our case. 

RE: porting from IIS

["Harold J. Ship" <Ha...@giant-steps-networks.com>]

>> How it works today: there are 3 types of request: light, medium and 
>> heavy.
>> We will need 2 "pools" of threads. One for handling light requests, 
>> and one for medium/heavy.

> That sounds rather like a new MPM.

>> The light requests can be dealt with by the usual mechanism.
>> The medium and heavy requests should be passed by the to the other 
>> thread pool, freeing the original "ordinary" thread to handle more 
>> incoming requests.

> That, on the other hand, sounds like solving a problem that isn't
there.  Unless you really need 
> priority queues, you can just let everything run in parallel.

Well, even a priority queue isn't enough. Suppose there are N threads
for handling requests. If N+M "heavy" requests come in a burst, then
there won't be any way to handle any "light" requests until at least M+1
"heavy" requests are completed. This would be the same even with a
priority queue.

If we can pass the heavies to another pool, they can take as long as
they need while incoming light requests are still serviced. Anyway, it
is a constraint already in place in the IIS application. We are simply
porting it.

>> We are worried that if we try to process the medium and heavy
requests 
>> with a thread pool, then either the "ordinary" thread will block 
>> anyway, or the next filter will get starved.

> Hmm?  Why do you suppose that?

Well, I don't "suppose" it so much as I just don't know enough about how
it works. For instance, I know that a filter reads its data in chunks
from a previous filter, and writes its data in chunks to the next filter
in the chain.  Is the next filter waiting, in the original thread, for
data from the content generator?

Most of our processing will be in the content generation hook. Will the
"gzip" or other filter block one of apache's threads while we generate
the content in another thread?

By the way, we've ordered "The Apache Modules Book" from Amazon but it
won't be here for another 3 weeks and we need to work now. We are trying
to get by with articles and examples we find on the internet, including
yours.

>> The heavy requests mentioned above are to be sent to another server.

> So that's a (reverse) proxy architecture.  Apache is happy with that,
and indeed it's a very common scenario.

Not exactly a reverse proxy in the usual sense because the other server
is not a web server. In fact in windows it's another process connected
using COM. We will probably wrap it with a web interface as an interim
solution until the other process can also be ported to Linux.

But essentially, you're right. And perhaps we can take advantage of
Apache's mod_proxy to do it. By the way, what happens with Apache's
thread after mod_proxy has forwarded the request until it receives a
response?

--
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: porting from IIS

[Nick Kew <ni...@webthing.com>]

On Thu, 24 Jul 2008 15:56:07 +0300
"Harold J. Ship" <Ha...@giant-steps-networks.com> wrote:


> How it works today: there are 3 types of request: light, medium and
> heavy.
> We will need 2 "pools" of threads. One for handling light requests,
> and one for medium/heavy.

That sounds rather like a new MPM.

> The light requests can be dealt with by the usual mechanism.
> The medium and heavy requests should be passed by the to the other
> thread pool, freeing the original "ordinary" thread to handle more
> incoming requests.

That, on the other hand, sounds like solving a problem that
isn't there.  Unless you really need priority queues, you can
just let everything run in parallel.

> We are worried that if we try to process the medium and heavy requests
> with a thread pool, then either the "ordinary" thread will block
> anyway, or the next filter will get starved.

Hmm?  Why do you suppose that?

> The heavy requests mentioned above are to be sent to another server.

So that's a (reverse) proxy architecture.  Apache is happy with that,
and indeed it's a very common scenario.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

RE: porting from IIS

["Harold J. Ship" <Ha...@giant-steps-networks.com>]

Nick: Thank you for your reply, but I still don't quite get it.

>> module on Linux.

> An apache module is normally cross-platform.

Yes I know, and we will try to make ours cross platform but I believe
there are some differences between Windows and Linux versions with
respect to threading.

>> 1) They maintain their own thread pool and scheduler. Those threads 
>> process requests and send responses back to the user agent. This
frees 
>> up IIS threads. Is this possible to do in Apache? By the way, they
use 
>> Extension Control Blocks to do that.

> Yes, if you're happy to limit it to threaded implementations.
> But it may not make sense.  See apr_thread_proc (and related APR
modules) for API.

We are trying to minimize the changes to the client's application code,
and so we will have to do it with threads.

How it works today: there are 3 types of request: light, medium and
heavy.
We will need 2 "pools" of threads. One for handling light requests, and
one for medium/heavy.
The light requests can be dealt with by the usual mechanism.
The medium and heavy requests should be passed by the to the other
thread pool, freeing the original "ordinary" thread to handle more
incoming requests.

We are worried that if we try to process the medium and heavy requests
with a thread pool, then either the "ordinary" thread will block anyway,
or the next filter will get starved.

Note: these request types can be identified by their URL.

>> 2) Some requests have "sub-requests" that are sent back through IIS.
>> The main request maintains some globally accessible data that the 
>> sub-requests write to. When the sub-requests are completed, the main 
>> request can use that data. Is this kind of thing possible in an
Apache 
>> module?

> Yep, no problem.  Most likely you'll want to let the subrequest access
its parent.

The heavy requests mentioned above are to be sent to another server. The
other server will send back http requests to apache which will need
access to the original request object. The worker MPM is usually run in
several processes. We will probably force it to run in a single process
and create a global memory pool.

We spent some time trying to get shared memory working and kept getting
the error: "Permission denied" from apr_global_mutext_lock.

--
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: porting from IIS

[Nick Kew <ni...@webthing.com>]

On Thu, 3 Jul 2008 17:02:19 +0300
"Harold J. Ship" <Ha...@giant-steps-networks.com> wrote:

> Hi
>  
> This is my first post to this list. I have a project coming up for a
> customer who wants to get their IIS extension working as an Apache
> module on Linux.

An apache module is normally cross-platform.

> Some of the challenges are:
>  
> 1) They maintain their own thread pool and scheduler. Those threads
> process requests and send responses back to the user agent. This frees
> up IIS threads. Is this possible to do in Apache? By the way, they use
> Extension Control Blocks to do that.

Yes, if you're happy to limit it to threaded implementations.
But it may not make sense.  See apr_thread_proc (and related
APR modules) for API.

> 2) Some requests have "sub-requests" that are sent back through IIS.
> The main request maintains some globally accessible data that the
> sub-requests write to. When the sub-requests are completed, the main
> request can use that data. Is this kind of thing possible in an Apache
> module?

Yep, no problem.  Most likely you'll want to let the subrequest access
its parent.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/