Re: problem with ap_md5 in custom module
Great! this fix the problem
thanks for your help.
On Wed, Aug 15, 2012 at 10:47 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Wed, Aug 15, 2012 at 5:13 PM, nik600 nik...@gmail.com wrote:
Dear all
i'm having a problem with ap_md5, i just want to write a custom module
that compute che md5 checksum of the requested url and give it back to
the user.
This is my code:
*
*
static int kcache_handler(request_rec* r)
{
if (!r-handler || strcmp(r-handler, kcache))
return DECLINED;
if (r-method_number != M_GET)
return HTTP_METHOD_NOT_ALLOWED;
char* kcache_md5;
kcache_md5 = (char *)ap_md5(r-pool,r-unparsed_uri);
ap_set_content_type(r, text/html;charset=ascii);
ap_rputs(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\, r);
ap_rputs(htmlheadtitleK-Hello World!/title/head, r);
ap_rprintf(r,bodyh1K-Hello
World!/h1p%s=%s/p/body/html, r-unparsed_uri,kcache_md5);
return OK;
}
*
*
i've got a warning during compilation:
src/mod_kcache.c:18:15: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
Is quite strange to me that ap_md5 returns an int, as in the
documentation it is reported to return a char *
http://ci.apache.org/projects/httpd/trunk/doxygen/group__APACHE__CORE__MD5.html
By the way, if i try to run it i get a segfault, if i comment the line
that prints kcache_md5 with ap_rprintf the module doesn't segfault.
So, where i'm wrong?
It seems you don't include util_md5.h so the compiler defaults the
function prototype to `int ap_md5()`. Compile with -Wall -Wextra and
you'll get warnings about things like that.
--
/*/
nik600
http://www.kumbe.it
Re: mod_fcgid concurrency bottleneck, issue#53693
On 8/15/2012 8:23 PM, pqf wrote: But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. Any other idea? Can we introduce a blocking call on 'pipe ready' based on the child spawn being ready to accept data? The equivalent of a ping-test?
Re: Re: mod_fcgid concurrency bottleneck, issue#53693
procmgr_post_spawn_cmd(maybe it should be renamed to procmgr_send_spawn_cmd) will keep blocking while PM is creating a new process, after procmgr_post_spawn_cmd() return, there should be a process ready there waiting for accept. 2012-08-16 pqf 发件人：William A. Rowe Jr. 发送时间：2012-08-16 15:23 主题：Re: mod_fcgid concurrency bottleneck, issue#53693 收件人：devdev@httpd.apache.org 抄送：pqfp...@mailtech.cn On 8/15/2012 8:23 PM, pqf wrote: But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. Any other idea? Can we introduce a blocking call on 'pipe ready' based on the child spawn being ready to accept data? The equivalent of a ping-test?
Re: Re: mod_fcgid concurrency bottleneck, issue#53693
2012/8/16 pqf p...@mailtech.cn: Hi, Michal My solution do add availability to each class, which is the procmgr_post_spawn_cmd() call in each loop do. The sleep() call is intrudused for a stress test without warm up time, in this case, mod_fcgid will create more processes than a slow start one(each process handler can't apply a free slot on the very begining, so send a request to process manager to create one, it's easy to reach the max # of process limit while httpd startup, but the idle process will be killed later), the sleep() call is a little like a server side warm up delay. But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. I was referring to the case where all processes are busy, without sleep(), handle_request() wil quickly send spawn requsts, whith will be denyed by process menager, with sleep() handle_request() will always wait quite a long time, occupying slots -- Michal Grzedzicki
回复: Re: Re: mod_fcgid concurrency bottleneck, issue#53693
How about this: 1. procmgr_post_spawn_cmd() now return a status code from PM, so process handler now know the spawn request is denyed or not. 2. if a new process is created, no sleep is needed. 3. if no process is created, sleep a while 2012-08-16 pqf 发件人：Lazy 发送时间：2012-08-16 16:47 主题：Re: Re: mod_fcgid concurrency bottleneck, issue#53693 收件人：devdev@httpd.apache.org 抄送： 2012/8/16 pqf p...@mailtech.cn: Hi, Michal My solution do add availability to each class, which is the procmgr_post_spawn_cmd() call in each loop do. The sleep() call is intrudused for a stress test without warm up time, in this case, mod_fcgid will create more processes than a slow start one(each process handler can't apply a free slot on the very begining, so send a request to process manager to create one, it's easy to reach the max # of process limit while httpd startup, but the idle process will be killed later), the sleep() call is a little like a server side warm up delay. But since someone said remove this sleep(), the server work fine without bottleneck(Maybe he didn't notise the warm up issue?), so I thought remove the sleep() is a good idea. But reduce the time of sleep() is fine to me too. I was referring to the case where all processes are busy, without sleep(), handle_request() wil quickly send spawn requsts, whith will be denyed by process menager, with sleep() handle_request() will always wait quite a long time, occupying slots -- Michal Grzedzicki
Re: Proposed TR for this Friday
The -deps tarball was hidden (one had to look around for it) so I just added a note that sometimes we provide it as a convenience. On Aug 15, 2012, at 4:52 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 14.08.2012 23:17, Jim Jagielski wrote: With my Mom's hospitalization and stuff, this kinda slipped... I hope she is doing better now. I propose this Friday: Aug 17th. Any conflicts?? You might want to take a look at http://svn.apache.org/viewvc?view=revisionrevision=r1241953 Since for 2.4.2 there was a deps tarball (and for 2.4.3 there will be again?) this might benefit from another rephrasing (plus sync with trunk where it was never applied). Regards, Rainer
Re: Linking mod_ssl with a specific OpenSSL version
On 12.8.12 20:01, Ben Laurie wrote:
On Sun, Aug 12, 2012 at 5:23 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
a workaround is to call configure with
suitable {CPP,LD}FLAGS, i.e.
CPPFLAGS=-I${openssl_build_dir}/include \
LDFLAGS=-L${openssl_build_dir} \
./configure ...
(when using the shared libssl/libcrypto libraries, adding
-Wl,-R${openssl_build_dir} or similar to LDFLAGS might make sense)
I haven't had time to retest it, but I think the problem with this
approach is that the default version of OpenSSL gets included first if
anything else uses /usr/local/{include,lib}. IIRC, this was the basis
of all my problems.
Ok, but then we're talking about a current limitation of the build
system, I think: the compile commands are put together in build/rules.mk
like this:
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
ALL_CPPFLAGS = $(DEFS) $(INTERNAL_CPPFLAGS) $(EXTRA_CPPFLAGS)
$(NOTEST_CPPFLAGS) $(CPPFLAGS)
[...]
ALL_INCLUDES = $(INCLUDES) $(EXTRA_INCLUDES)
# Compile commands
BASE_CC = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
Both $EXTRA_CPPFLAGS and $EXTRA_INCLUDES are assembled by configure,
where each module can contribute its stuff (appended with APR_ADDTO,
usually). I.e., if you happen to configure mod_deflate with a zlib
in /usr/local, then you end up with $EXTRA_INCLUDES where mod_deflate's
-I/usr/local precedes -I/path/to/openssl/build/dir (since
modules/filter/config.m4 is run before modules/ssl/config.m4).
Similarly, for linking we have:
ALL_LDFLAGS = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)
[...]
LINK = $(LIBTOOL) --mode=link $(CC) $(ALL_CFLAGS) $(LT_LDFLAGS)
$(ALL_LDFLAGS) -o $@
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands, i.e. in rules.mk we would have:
ALL_CFLAGS = $(MOD_CFLAGS) $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
ALL_CPPFLAGS = $(DEFS) $(INTERNAL_CPPFLAGS) $(MOD_CPPFLAGS) $(EXTRA_CPPFLAGS)
$(NOTEST_CPPFLAGS) $(CPPFLAGS)
ALL_INCLUDES = $(INCLUDES) $(MOD_INCLUDES) $(EXTRA_INCLUDES)
ALL_LDFLAGS = $(MOD_LDFLAGS) $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)
A particular module could then set its specific MOD_CFLAGS etc. in
modules.mk, and these would always have priority over those possibly
inserted by other modules.
Kaspar
