C++ and apache development
Hi, If I would like to use c++ to write dynamic web server applications, what is the best resource for me that I can use with apache? I believe I have the following options: 1. apache module like mod_php or mod_perl 2. application server that interacts with apache like tomcat 3. CGI 4. FastCGI Are there any maintaned modules for C++ like mod_php and mod_perl. I've had a look at codeo and mod_cpp but they dont seem to be maintained? I have looked into fastcgi (and it seems promising). Is is a best trend now a days due to stabilitiy issues to keep the custom server as a separate process (like above 2, 3 and 4). Have you used one of the above options and what are the side affects to it? Thanks Shams --
-T commandline argument for 2.0.x
Please have a look at bug/patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=41887 This is my first ever contribution to an OS project of such, and therefore I'd like to know the chances of getting this patch in the main tree. If I need to alter the patch for this to happen, let me know. (ie did I use the correct variable naming, are the declarations in the right header files etc.?) This patch/option greatly improved my own server performance so I would really like to see it join the main source tree. (I mainly use 2.0.x so therefore the patch is for 2.0.x. When needed I could probably create one for 2.3.0) Cheers, Jan
Re: -T commandline argument for 2.0.x
On Mon, 19 Mar 2007 12:06:03 +0100 Jan van den Berg [EMAIL PROTECTED] wrote: Please have a look at bug/patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=41887 This is my first ever contribution to an OS project of such, and therefore I'd like to know the chances of getting this patch in the main tree. First impression: the patch makes sense. And now it's available on bugzilla for anyone who looks. But it's of limited applicability, because the problem it fixes is just one of many serious drawbacks of running large numbers of vhosts without using a mass-virtual-hosting solution. Getting it adopted depends on finding support amongst committers. In the case of a patch that isn't fixing a security issue or some howler of a bug, that's much more likely to happen in /trunk/ (and thence 2.2) than in 2.0. If there were patches against all three branches, there's a chance they'd all be applied. If I need to alter the patch for this to happen, let me know. (ie did I use the correct variable naming, are the declarations in the right header files etc.?) Looks fine to me. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_cgid and accept() loop
On 3/18/07, Amol Dev [EMAIL PROTECTED] wrote: Just have to make sure the daemon will be relaunched taking on requests without problem if that happens. Yes (not tested exactly like that however). Certainly the cgid daemon would be relaunched if it crashed.
Re: [RFC] Guide to writing output filters
Thanks a lot for the review! On Sat, Mar 17, 2007 at 04:30:24PM +0100, Ruediger Pluem wrote: Some comments from my side: - Passing empty brigades: While I agree that a filter should never create an empty brigade and pass it down the chain, I think it actually should pass an empty brigade down the chain if it gets one passed instead of simply returning. For reasons why see http://issues.apache.org/bugzilla/show_bug.cgi?id=40090 http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED] This is interesting, but I don't really understand how the problem described happens. How is ap_finalize_request_protocol() getting called before a response has been sent? (there is some symmetry between that problem and PR 38014) - apr_brigade_destroy: I think the danger about using apr_brigade_destroy is to call it and *reuse* this brigade afterwards, because in this case the removed pool cleanup can cause a memory leak. Right - and that should be true of every brigade which a filter uses (the passed-in brigade should not be destroyed; any brigades the filter itself creates *must* be long-lived and re-used). So there's really no case in which to recommend use of apr_brigade_destroy() for a filter. It's almost always safer to use _cleanup. I'll add a note about using _cleanup() to this section. - Procesing buckets: I think with mmap enabled a file bucket will morph into a mmap bucket and the remaining file bucket. I think the heap bucket will only be created if mmap is turned off. But I agree that this possibly introduces too much complexity to the example and distracts the reader from the important point. Yeah. It's an implementation detail, and the risk is that if it gets documented, people will rely on it somehow. - Filtering brigades: - Although this is not my opinion I know that there had been some discussions in the past that no examples should be given on how you should *not* do things. I was wary of doing this too, but it's such a common mistake that I thought it to explain explicitly why it's bad. - Maintaining state: - f-ctx = state = apr_palloc(sizeof(*state), f-r-pool); instead of f-ctx = state = apr_palloc(sizeof *state, f-r-pool); ? I vaguely prefer sizeof without the brackets where valid ;) - IMHO ap_save_brigade can operate on an existing brigade. So this can be a brigade created once per invocation. I agree with the warning that especially on PIPE buckets ap_save_brigade can consume quite a lot of memory. Plus ap_save_brigade does a blocking read on the bucket. Good points, I'll add some text. joe
Re: mod_proxy patches
On Mar 16, 2007, at 8:52 AM, Mathias Herberts wrote: I agree that reusing the backend connections can be a good thing, but there are times when this is just not a very good idea. I agree that there are times when having a single-shot connection is better than having a pool. It's certainly not a normal situation but for those people affected by this, it's a deal-breaker.
RE: -T commandline argument for 2.0.x
Hi, Thanks for the advise; I also added a patch for the current trunk (updated 'bug' report). Interesting fact you brought up about mass virtual hosting. I was thinking about this and theoretically I could write a module to handle this. With all my vh info stored in a database. This module would handle the requests and pull stuff from the database and store this in memory with some sort of timestamp and serve the files from there. When the timestamp expires, information again is pulled from the database etc. This way I would probably never need a graceful; right? Mmmm something to think about and maybe give a try when I have some free time on my hands. But for now I'd still really like to see this patch go in the trunk. Cheers, Jan -Oorspronkelijk bericht- Van: Nick Kew [mailto:[EMAIL PROTECTED] Verzonden: maandag 19 maart 2007 12:32 Aan: dev@httpd.apache.org Onderwerp: Re: -T commandline argument for 2.0.x On Mon, 19 Mar 2007 12:06:03 +0100 Jan van den Berg [EMAIL PROTECTED] wrote: Please have a look at bug/patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=41887 This is my first ever contribution to an OS project of such, and therefore I'd like to know the chances of getting this patch in the main tree. First impression: the patch makes sense. And now it's available on bugzilla for anyone who looks. But it's of limited applicability, because the problem it fixes is just one of many serious drawbacks of running large numbers of vhosts without using a mass-virtual-hosting solution. Getting it adopted depends on finding support amongst committers. In the case of a patch that isn't fixing a security issue or some howler of a bug, that's much more likely to happen in /trunk/ (and thence 2.2) than in 2.0. If there were patches against all three branches, there's a chance they'd all be applied. If I need to alter the patch for this to happen, let me know. (ie did I use the correct variable naming, are the declarations in the right header files etc.?) Looks fine to me. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_proxy patches
Jim Jagielski wrote: On Mar 16, 2007, at 8:52 AM, Mathias Herberts wrote: I agree that reusing the backend connections can be a good thing, but there are times when this is just not a very good idea. I agree that there are times when having a single-shot connection is better than having a pool. I agree with you, but in that case, using a http instead ajp is a better alternative. Unlike with mod_jk, with mod_proxy we have an option to choose the appropriate protocol. Regards, Mladen.
Re: [RFC] Guide to writing output filters
Again, thanks for the review! On Sat, Mar 17, 2007 at 07:44:02AM -0400, Jeff Trawick wrote: I guess I'm confused about the up/down direction convention for output filters? I thought passing the next output filter is down and returning to the prior input filter is up? My confusion - I always think about filters in terms of the call stack, where ap_pass_brigade passes brigades up the stack. More detail about error handling would be invaluable. Something that has been a thorn in the past has been the two types of status and understanding the limited relationship: apr_status_t as returned by a filter HTTP status as returned by a handler What can a filter do to influence HTTP status (set r-status on first invocation for a response?)? What will be logged if a filter returns non-APR_SUCCESS? Excellent questions for which I lack excellent answers :) Also: is it better to use the elusive HTTP error bucket rather than setting r-status? What should filters do with apr_bucket_read() errors? Must filters _cleanup() the brigade before returning an error? (there is a bug in bugzilla caused by that one IIRC) joe
RE: -T commandline argument for 2.0.x
http://www.outoforder.cc/projects/apache/mod_vhost_dbi/ This looks exactly like what I was talking about. -Oorspronkelijk bericht- Van: Jan van den Berg [mailto:[EMAIL PROTECTED] Verzonden: maandag 19 maart 2007 15:47 Aan: dev@httpd.apache.org Onderwerp: RE: -T commandline argument for 2.0.x Hi, Thanks for the advise; I also added a patch for the current trunk (updated 'bug' report). Interesting fact you brought up about mass virtual hosting. I was thinking about this and theoretically I could write a module to handle this. With all my vh info stored in a database. This module would handle the requests and pull stuff from the database and store this in memory with some sort of timestamp and serve the files from there. When the timestamp expires, information again is pulled from the database etc. This way I would probably never need a graceful; right? Mmmm something to think about and maybe give a try when I have some free time on my hands. But for now I'd still really like to see this patch go in the trunk. Cheers, Jan -Oorspronkelijk bericht- Van: Nick Kew [mailto:[EMAIL PROTECTED] Verzonden: maandag 19 maart 2007 12:32 Aan: dev@httpd.apache.org Onderwerp: Re: -T commandline argument for 2.0.x On Mon, 19 Mar 2007 12:06:03 +0100 Jan van den Berg [EMAIL PROTECTED] wrote: Please have a look at bug/patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=41887 This is my first ever contribution to an OS project of such, and therefore I'd like to know the chances of getting this patch in the main tree. First impression: the patch makes sense. And now it's available on bugzilla for anyone who looks. But it's of limited applicability, because the problem it fixes is just one of many serious drawbacks of running large numbers of vhosts without using a mass-virtual-hosting solution. Getting it adopted depends on finding support amongst committers. In the case of a patch that isn't fixing a security issue or some howler of a bug, that's much more likely to happen in /trunk/ (and thence 2.2) than in 2.0. If there were patches against all three branches, there's a chance they'd all be applied. If I need to alter the patch for this to happen, let me know. (ie did I use the correct variable naming, are the declarations in the right header files etc.?) Looks fine to me. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [RFC] Guide to writing output filters
On 03/19/2007 03:06 PM, Joe Orton wrote: Thanks a lot for the review! On Sat, Mar 17, 2007 at 04:30:24PM +0100, Ruediger Pluem wrote: Some comments from my side: - Passing empty brigades: While I agree that a filter should never create an empty brigade and pass it down the chain, I think it actually should pass an empty brigade down the chain if it gets one passed instead of simply returning. For reasons why see http://issues.apache.org/bugzilla/show_bug.cgi?id=40090 http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED] This is interesting, but I don't really understand how the problem described happens. How is ap_finalize_request_protocol() getting called before a response has been sent? (there is some symmetry between that Once we detect that we have a fresh content entity in the cache, the quick handler of mod_cache starts the filter chain by calling ap_pass_brigade(r-output_filters, out); where out is an empty brigade created by the quick handler. The brigade gets filled with the cached content by the CACHE_OUT filter down in the chain. In the original code path and PR configuration mod_deflate was the first filter in r-output_filters which caused the filter chain to return immediately and before it reached the CACHE_OUT filter (mod_deflate detected an empty brigade and returned APR_SUCCESS). This caused the quick handler of mod_cache to be left with OK, which triggers ap_finalize_request_protocol. The correct fix in this situation of cause was to remove all filters from r-output_filters until we hit mod_cache's CACHE_OUT filter, because this is the position in the filter chain where the content went to the cache during caching. problem and PR 38014) I think PR 38014 is somewhat different. The ap_http_filter simply was not completely aware that it could be called in two situations: - During request processing. - After request processing in order to cleanup the connection. - apr_brigade_destroy: I think the danger about using apr_brigade_destroy is to call it and *reuse* this brigade afterwards, because in this case the removed pool cleanup can cause a memory leak. Right - and that should be true of every brigade which a filter uses (the passed-in brigade should not be destroyed; any brigades the filter itself creates *must* be long-lived and re-used). So there's really no case in which to recommend use of apr_brigade_destroy() for a filter. The only possible one from my perspective is on a brigade that was created by the filter as long lived state brigade in the case that the filter either sees an EOS bucket or decides to remove itself from the filter chain for some other reason. But even in this case _cleanup is sufficient. We can only save walking thru the brigades pool cleanup once the pool used for its creation gets destroyed. It's almost always safer to use _cleanup. Agreed. Seeing an apr_brigade_destroy in a filter should ring an alarm bell. I'll add a note about using _cleanup() to this section. - Procesing buckets: I think with mmap enabled a file bucket will morph into a mmap bucket and the remaining file bucket. I think the heap bucket will only be created if mmap is turned off. But I agree that this possibly introduces too much complexity to the example and distracts the reader from the important point. Yeah. It's an implementation detail, and the risk is that if it gets documented, people will rely on it somehow. Why can't you rely on this? Isn't that the publicly defined behaviour of a file bucket when MMAP is enabled? Regards Rüdiger
Input Needed on Bug 38515
I'm determined to push through a patch for Bug 38515 - Dynamic LDAP Group Support, but I could use some input regarding the recommended approach. I've outlined a basic plan on the bug page (http://issues.apache.org/bugzilla/show_bug.cgi?id=38515) and would appreciate any comments more experienced developers have. Thanks in advance, Gregory Szorc [EMAIL PROTECTED]
