Re: maintainer mode and test framework
On Mon, Aug 24, 2015 at 9:41 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: mod_test_session.c did some non C90 variable declarations intermixed with code. I'll check in the fix shortly. Btw. what is holding us back from more recent C? Old platforms, obviously... Do we have an idea which? Ah, that is a brand new test module committed this month. I am not sure exactly where we really have the constraint. Visual Studio 6 on Windows in the old releases? I think my own pet/corporate overlord platforms (z/OS, AIX) are not an issue.
maintainer mode and test framework
Just a tiny question how the senior guys here do to: If I build httpd in maintainer-mode (which I want), the test framework will no longer build since it inherits the compiler flags from apxs, I assume. Is there an easy way around this? //Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: maintainer mode and test framework
On Mon, Aug 24, 2015 at 9:23 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Just a tiny question how the senior guys here do to: If I build httpd in maintainer-mode (which I want), the test framework will no longer build since it inherits the compiler flags from apxs, I assume. Is there an easy way around this? You could edit build/config_vars.mk in a pinch. I don't think I've ever had that harm the test framework. What fails in the framework?
Re: maintainer mode and test framework
OK, now you made me fix it. ;-) mod_test_session.c did some non C90 variable declarations intermixed with code. I'll check in the fix shortly. Btw. what is holding us back from more recent C? Old platforms, obviously... Do we have an idea which? Am 24.08.2015 um 15:24 schrieb Eric Covener cove...@gmail.com: On Mon, Aug 24, 2015 at 9:23 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Just a tiny question how the senior guys here do to: If I build httpd in maintainer-mode (which I want), the test framework will no longer build since it inherits the compiler flags from apxs, I assume. Is there an easy way around this? You could edit build/config_vars.mk in a pinch. I don't think I've ever had that harm the test framework. What fails in the framework? green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
regression tests
I seem to get Test Summary Report --- t/filter/case.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 in regression tests since my vacation. Anything rings a bell? green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: maintainer mode and test framework
On Aug 24, 2015 08:45, Eric Covener cove...@gmail.com wrote: On Mon, Aug 24, 2015 at 9:41 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: mod_test_session.c did some non C90 variable declarations intermixed with code. I'll check in the fix shortly. Btw. what is holding us back from more recent C? Old platforms, obviously... Do we have an idea which? Ah, that is a brand new test module committed this month. I am not sure exactly where we really have the constraint. Visual Studio 6 on Windows in the old releases? I think my own pet/corporate overlord platforms (z/OS, AIX) are not an issue. No issue on MS, plenty of more modern compilers, but MS C has been MS C++ with all sort of other oddities forever. I am thinking oddballs like hpux and old Solaris compilers, but in trunk do we really need to keep accommodating for httpd 2.6/3.0? In the test suite, since it is used to validate legacy httpd, it seems prudent to keep compatibility for a while longer still.
PR 58267: Regression in 2.2.31 caused by r1680920
Hi, unfortunately, the r1680920 brought undesired behavior described in PR 58267 to 2.2.x. The bug is well described in the PR, so I won't describe it in this email. I have tried to debug it and I think the problem is that we use also server-server_hostname to compute the hash in the ap_proxy_set_scoreboard_lb. This hash is used to find out proper ap_scoreboard field. It all happens in mod_proxy.c:child_init's scope. If the Proxy Balancer://foobar has been defined, all the BalancerMembers are initialized with the hash computed with usage of global server-server_hostname. Later, if the ProxyPass /foobar/ Balancer://foobar/ has been used in the VirtualHost, ap_proxy_initialize_worker_share is called again with server-server_hostname set to the VirtualHost's one. Now, the root of the error is that the scoreboard size is static (set to proxy_lb_workers + PROXY_DYNAMIC_BALANCER_LIMIT), but it is not incremented when ProxyPass with balancer is used in the virtualhost. This leads to lack of space in scoreboard when Balancers are used in multiple virtualhosts. I think there are two possible fixes: 1) Do not use server-server_hostname when computing hash which is used to determine right scoreboard field. I think this would fix this bug, but I'm not sure what would happen in situations when you define 2 balancers with the same name in different virtualhosts... On the other-side, when there is global Proxy balancer, it make sense to use the same worker-s for all the ProxyPass in virtualhosts. 2) Increment proxy_lb_workers according to number of workers in balancer when using ProxyPass /foobar/ Balancer://foobar/ in the VirtualHost. The scoreboard would have right size and ap_proxy_set_scoreboard_lb would not fail then. Since it's 2.2.x which should be probably stable without big changes, I'm asking the list for more opinions... I will try to implement patch for option 2) tomorrow and see if this really fixes the issue. Regards, Jan Kaluza
Re: PR 58267: Regression in 2.2.31 caused by r1680920
On 08/24/2015 04:47 PM, Jan Kaluža wrote: Hi, unfortunately, the r1680920 brought undesired behavior described in PR 58267 to 2.2.x. The bug is well described in the PR, so I won't describe it in this email. I have tried to debug it and I think the problem is that we use also server-server_hostname to compute the hash in the ap_proxy_set_scoreboard_lb. This hash is used to find out proper ap_scoreboard field. It all happens in mod_proxy.c:child_init's scope. If the Proxy Balancer://foobar has been defined, all the BalancerMembers are initialized with the hash computed with usage of global server-server_hostname. Later, if the ProxyPass /foobar/ Balancer://foobar/ has been used in the VirtualHost, ap_proxy_initialize_worker_share is called again with server-server_hostname set to the VirtualHost's one. Now, the root of the error is that the scoreboard size is static (set to proxy_lb_workers + PROXY_DYNAMIC_BALANCER_LIMIT), but it is not incremented when ProxyPass with balancer is used in the virtualhost. This leads to lack of space in scoreboard when Balancers are used in multiple virtualhosts. I think there are two possible fixes: 1) Do not use server-server_hostname when computing hash which is used to determine right scoreboard field. I think this would fix this bug, but I'm not sure what would happen in situations when you define 2 balancers with the same name in different virtualhosts... On the other-side, when there is global Proxy balancer, it make sense to use the same worker-s for all the ProxyPass in virtualhosts. It seems that 2.4.x uses just the name of the worker to determine slot for shared memory, so maybe it wouldn't be a problem for 2.2.x too... Jan Kaluza 2) Increment proxy_lb_workers according to number of workers in balancer when using ProxyPass /foobar/ Balancer://foobar/ in the VirtualHost. The scoreboard would have right size and ap_proxy_set_scoreboard_lb would not fail then. Since it's 2.2.x which should be probably stable without big changes, I'm asking the list for more opinions... I will try to implement patch for option 2) tomorrow and see if this really fixes the issue. Regards, Jan Kaluza
Re: Fwd: Unexpected Warnings from Macro Use in 2.4
On Mon, Aug 24, 2015 at 11:21 AM, Rainer Jung rainer.j...@kippdata.de wrote:
think it would be better if httpd core (${x}) and mod_rewrite (%{x}) could
stay as-is and mod_macro would support yet another prefix like .
+1
--
Eric Covener
cove...@gmail.com
Re: Fwd: Unexpected Warnings from Macro Use in 2.4
Am 24.08.2015 um 13:40 schrieb Nick Gearls:
This is definitely a bug as we have a major incompatibility between two
features.
Remark: although mod_macro can use $ and % for unescaped characters,
${x} is used by Define and %{x} by mod_rewrite :-(
Shooting from the hip:
{x}
Haven't checked for implications, but adding to mod_macro with the
same meaning as $ and % looks trivial to do.
I suppose the preferred solution to not be incompatible with the current
situation would be an optional directive to overwrite the $ character
(DefineChar?)
I think it would be better if httpd core (${x}) and mod_rewrite (%{x})
could stay as-is and mod_macro would support yet another prefix like
. Note that there is already support for @{x}, but that has slightly
different semantics (which doesn't matter in many cases).
Another thing: apart from us providing better and unambiguous syntax, it
would always be a good idea not to use the same names for macro
variables and system environment resp. Define variables in your
configuration. Otherwise chances are good someone (admin) or something
(software) will misinterpret what actually happens or should happen.
Regards,
Rainer
Forwarded Message
Subject: Re: Unexpected Warnings from Macro Use in 2.4
Date: Sat, 22 Aug 2015 11:16:44 -0500
From: Tom Browder tom.brow...@gmail.com
To: nickgea...@gmail.com, dev@httpd.apache.org dev@httpd.apache.org
On Tue, Feb 24, 2015 at 7:15 AM, Tom Browder tom.brow...@gmail.com wrote:
On Feb 24, 2015 6:52 AM, Nick Gearls nickgea...@gmail.com wrote:
Define mysite www.mycompany.com
Macro NewSite $mysite
Servername${mysite}
ErrorLog /var/log/httpd/${mysite}_error.log
/Macro
Use NewSite www.company1.com
Use NewSite www.company2.com
That's similar to the way I use it for multiple virtual hosts and have no
problems except the warnings I reported.
The problem still exists in 2.4.16. Shall I file a bug?
-Tom
Re: PR 58267: Regression in 2.2.31 caused by r1680920
Hi Jan, I was working on the same issue... and was going to implement 2) :) On Mon, Aug 24, 2015 at 4:47 PM, Jan Kaluža jkal...@redhat.com wrote: Now, the root of the error is that the scoreboard size is static (set to proxy_lb_workers + PROXY_DYNAMIC_BALANCER_LIMIT), but it is not incremented when ProxyPass with balancer is used in the virtualhost. This leads to lack of space in scoreboard when Balancers are used in multiple virtualhosts. I came to the same conclusion. I think there are two possible fixes: 1) Do not use server-server_hostname when computing hash which is used to determine right scoreboard field. I think this would fix this bug, but I'm not sure what would happen in situations when you define 2 balancers with the same name in different virtualhosts... They should be different balancers... On the other-side, when there is global Proxy balancer, it make sense to use the same worker-s for all the ProxyPass in virtualhosts. This would break compatibility. 2) Increment proxy_lb_workers according to number of workers in balancer when using ProxyPass /foobar/ Balancer://foobar/ in the VirtualHost. The scoreboard would have right size and ap_proxy_set_scoreboard_lb would not fail then. I think we can do this quite easily in merge_proxy_config(), by incrementing proxy_lb_workers for each base-balancers-workers. I did not test it yet though. Regards, Yann.
protocols and mod_h2 consolidation
As you might have noticed, I am doing some cleanup work on mod_h2 and want to create THE PATCH for backporting soon. The new core directives Protocols and ProtocolsHonorOrder are implemented, such as on a server or virtual host one may write Protocols h2c http/1.1 # enable h2c and http/1.1 here, preference decided by client ordering Protocols http/1.1 # only allow http/1.1 here Protocols h2 http/1.1 # enable h2c and http/1.1 here, with preference to h2 ProtocolsHonorOrder on Protocols YOLO h2 http/1.1 # enable YOLO protocol among others, which has no effect unless a module claims to implement it. With no Protocols specified, all protocols offered by the client and implemented by a module may be negotiated with the preference being in the client's ordering. This allows drop in of protocol modules without further configuration. Inheritance of Protocols between servers and virtual hosts is copyOrReplace, meaning vhosts without Protocols inherit from base server. vhosts with a Protocols ignore base server lists. This allows restrictions in the vhosts at the cost of some redundancy. But Protocols differences between base servers and vhosts seem to be rather esotheric right now. So, I tried to keep it simple. The ProtocolsHonorOrder name I tried to name in the spirit of the SSLHonorCipherOrder directive. No strong feelings about it. I hope this works for everyone. The next weeks might be a good time to think about it and propose any changes and correct my mistakes. Thanks. green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: protocols and mod_h2 consolidation
On Mon, Aug 24, 2015 at 12:29 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I hope this works for everyone. The next weeks might be a good time to think about it and propose any changes and correct my mistakes. Look good in concept to me
Re: svn commit: r1696105 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_socache_memcache.xml modules/cache/mod_socache_memcache.c
Hi, Yann and thanks for the review.
Le 21/08/2015 15:47, Yann Ylavic a écrit :
On Sun, Aug 16, 2015 at 12:05 AM, jaillet...@apache.org wrote:
Author: jailletc36
Date: Sat Aug 15 22:05:08 2015
New Revision: 1696105
URL: http://svn.apache.org/r1696105
[]
Modified: httpd/httpd/trunk/modules/cache/mod_socache_memcache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_socache_memcache.c?rev=1696105r1=1696104r2=1696105view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_socache_memcache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_socache_memcache.c Sat Aug 15 22:05:08
2015
[]
@@ -310,6 +319,35 @@ static const ap_socache_provider_t socac
[]
+static const char *socache_mc_set_ttl(cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+socache_mc_svr_cfg *sconf =
ap_get_module_config(cmd-server-module_config,
+ socache_memcache_module);
+int i;
+
+i = atoi(arg);
+
+if ((i 1) || (i 1800)) {
Why a limit of 1800? Maybe the implicit INT_MAX is good enough.
Also the memcached may never close its connections by itself, or
always do, so -1 and 0 could also be interesting...
Obviously 0 should be allowed, but I don't see any reason for -1. What
difference would you make between the 2?
INT_MAX on a 32 bits system is 2147483647. I considered that giving the
TTL in sec was enough and more standard. This has to be converted to sec.
So, the maximum allowed value would be 2147. 1800 (half an hour) looked
a more logical value for an end user. That's why I have chosen this limit.
Maybe up to 3600 (an hour) should also be allowed as it is accepted by
apr_memcache_server_create.
+return apr_pstrcat(cmd-pool, cmd-cmd-name,
+must be a number between 1 and 1800., NULL);
+}
+
+/* apr_memcache_server_create needs a ttl in usec. */
+sconf-ttl = i * 1000 * 1000;
sconf-ttl = apr_time_from_sec(i) ?
Didn't do that because of the the different type (apr_time_t (i.e.
apr_int64_t) vs apr_uint32_t)
But using apr_time_from_sec looks good and self-document the code (i.e.
ttl in usec)
+
+return NULL;
+}
Regards,
Yann.
Re: svn commit: r1696960 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/proxy/mod_proxy_balancer.c
On Fri, Aug 21, 2015 at 8:07 PM, Ruediger Pluem rpl...@apache.org wrote: On 08/21/2015 07:02 PM, Yann Ylavic wrote: On Fri, Aug 21, 2015 at 4:15 PM, Ruediger Pluem rpl...@apache.org wrote: Hm. Doesn't that mean that if I keep on adding stuff and do graceful restarts that at one point in time I will have used up all my growth and need to do a hard restart? Yes, the last restart would fail. If yes, it should be probably documented to avoid some unexpected surprises. I agree it should be documented (will do), currently we already have this issue from the first restart though. So it is an improvement over what we have :-) Yes, including the doc :) Added in r1697352, and to the backport proposal. Thanks, Yann.
Re: modules\http2 - H2Engine directive?
Ni Norm, yes, I removed it last week and though I removed it from the doc xml as well. Seems I forgot the Readme. Will fix soon. Sorry for any confusion. //Stefan Am 24.08.2015 um 05:53 schrieb NormW no...@gknw.net: Hi, The 'H2Engine on' directive is identified in the Readme.h2 as the most important, but except for a number of 'Directive' lists and a h2.conf template file. this appears to be unknown within the http2 C source or the 'manual'(en) reference for mod_h2. Is this directive something of the past or future perhaps? Regards, Norm green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: modules\http2 - H2Engine directive?
Hi Stefan, Thanks for the clarification! A text search for 'H2Engine' shows it in a number of other languages under '.\manual\mod\directives', 'manual\mod\quickreference' and in '\docs\conf\extra\httpd-h2.conf.in'. HTH, Thanks, Norm On 24/08/2015 6:06 PM, Stefan Eissing wrote: Ni Norm, yes, I removed it last week and though I removed it from the doc xml as well. Seems I forgot the Readme. Will fix soon. Sorry for any confusion. //Stefan Am 24.08.2015 um 05:53 schrieb NormW no...@gknw.net: Hi, The 'H2Engine on' directive is identified in the Readme.h2 as the most important, but except for a number of 'Directive' lists and a h2.conf template file. this appears to be unknown within the http2 C source or the 'manual'(en) reference for mod_h2. Is this directive something of the past or future perhaps? Regards, Norm green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: svn commit: r1696105 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_socache_memcache.xml modules/cache/mod_socache_memcache.c
On Mon, Aug 24, 2015 at 8:17 AM, Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:
Le 21/08/2015 15:47, Yann Ylavic a écrit :
On Sun, Aug 16, 2015 at 12:05 AM, jaillet...@apache.org wrote:
+if ((i 1) || (i 1800)) {
Why a limit of 1800? Maybe the implicit INT_MAX is good enough.
Also the memcached may never close its connections by itself, or
always do, so -1 and 0 could also be interesting...
Obviously 0 should be allowed, but I don't see any reason for -1. What
difference would you make between the 2?
Hm, I thought that for apr_memcache_server_create (hence
apr_reslist_create), ttl=0 was always close (immediately) and -1 was
never close (infinite), but that's not the case (ttl=0 means never
close, and -1 is invalid).
I don't know if memcached can be configured to always close the
connections when done (I guess so), but since the minimal TTL is 1
second, we could end up reusing connections closed remotely (without
recovering on error) in this case.
So maybe our best option is to use ap_timeout_parameter_parse() to set
sconf-ttl, which would allow a TTL of 1 microsecond (min), and almost
no max (native 64bit apr_time_t)...
Regards,
Yann.
Re: svn commit: r1697322 - /httpd/httpd/branches/2.4.x/STATUS
On Mon, 24 Aug 2015 07:40:33 -
rpl...@apache.org wrote:
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Aug 24 07:40:33 2015
@@ -238,8 +238,15 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
+1: rpluem, ylavic
niq: 1. the if(worker-s-retries) {} and comment at line 2917
don't seem to make any sense.
+ rpluem: This is just taken over from existing code. It is just indented
+ differently hence part of the path I think it should be marked
+ as TODO section. But this should be subject to another
+ patch.
Agreed it comes from existing code, but I wonder if its meaning and purpose
haven't got lost since it was originally written?
I'm +1 if that's either removed or if the comment clarifies what
actual case the TODO would be dealing with.
--
Nick Kew
Fwd: Unexpected Warnings from Macro Use in 2.4
This is definitely a bug as we have a major incompatibility between two
features.
Remark: although mod_macro can use $ and % for unescaped characters,
${x} is used by Define and %{x} by mod_rewrite :-(
I suppose the preferred solution to not be incompatible with the current
situation would be an optional directive to overwrite the $ character
(DefineChar?)
Forwarded Message
Subject:Re: Unexpected Warnings from Macro Use in 2.4
Date: Sat, 22 Aug 2015 11:16:44 -0500
From: Tom Browder tom.brow...@gmail.com
To: nickgea...@gmail.com, dev@httpd.apache.org dev@httpd.apache.org
On Tue, Feb 24, 2015 at 7:15 AM, Tom Browder tom.brow...@gmail.com wrote:
On Feb 24, 2015 6:52 AM, Nick Gearls nickgea...@gmail.com wrote:
Define mysite www.mycompany.com
Macro NewSite $mysite
Servername${mysite}
ErrorLog /var/log/httpd/${mysite}_error.log
/Macro
Use NewSite www.company1.com
Use NewSite www.company2.com
That's similar to the way I use it for multiple virtual hosts and have no
problems except the warnings I reported.
The problem still exists in 2.4.16. Shall I file a bug?
-Tom
Re: Unexpected Warnings from Macro Use in 2.4
On Mon, Aug 24, 2015 at 7:40 AM, Nick Gearls nickgea...@gmail.com wrote:
Remark: although mod_macro can use $ and % for unescaped characters, ${x} is
used by Define and %{x} by mod_rewrite :-(
Just to make sure it's clear, ${x} is even older then Define and is
used to resolve real native environment variables.
Re: PR 58267: Regression in 2.2.31 caused by r1680920
On Mon, Aug 24, 2015 at 5:51 PM, Yann Ylavic ylavic@gmail.com wrote:
On Mon, Aug 24, 2015 at 4:47 PM, Jan Kaluža jkal...@redhat.com wrote:
2) Increment proxy_lb_workers according to number of workers in balancer
when using ProxyPass /foobar/ Balancer://foobar/ in the VirtualHost. The
scoreboard would have right size and ap_proxy_set_scoreboard_lb would not
fail then.
I think we can do this quite easily in merge_proxy_config(), by
incrementing proxy_lb_workers for each base-balancers-workers. I did
not test it yet though.
I tested the below which seems to work.
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c(revision 1697358)
+++ modules/proxy/mod_proxy.c(working copy)
@@ -1135,6 +1135,7 @@ static void * create_proxy_config(apr_pool_t *p, s
static void * merge_proxy_config(apr_pool_t *p, void *basev, void *overridesv)
{
+int i;
proxy_server_conf *ps = apr_pcalloc(p, sizeof(proxy_server_conf));
proxy_server_conf *base = (proxy_server_conf *) basev;
proxy_server_conf *overrides = (proxy_server_conf *) overridesv;
@@ -1147,6 +1148,13 @@ static void * merge_proxy_config(apr_pool_t *p, vo
ps-allowed_connect_ports = apr_array_append(p,
base-allowed_connect_ports, overrides-allowed_connect_ports);
ps-workers = apr_array_append(p, base-workers, overrides-workers);
ps-balancers = apr_array_append(p, base-balancers, overrides-balancers);
+/* The balancers inherited from base don't have their members reserved on
+ * the scorebord_lb for this server, account for them now.
+ */
+for (i = 0; i base-balancers-nelts; ++i) {
+proxy_balancer *balancer = (proxy_balancer *)base-balancers-elts + i;
+proxy_lb_workers += balancer-workers-nelts;
+}
ps-forward = overrides-forward ? overrides-forward : base-forward;
ps-reverse = overrides-reverse ? overrides-reverse : base-reverse;
--
Please note that since all the workers would really be accounted in
the scoreboard, configurations like the one of PR 58267 (with
inherited balancers) would also need bigger SHMs (but no more) than
currently...
WDYT?
Re: svn commit: r1696105 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_socache_memcache.xml modules/cache/mod_socache_memcache.c
Le 24/08/2015 11:18, Yann Ylavic a écrit :
On Mon, Aug 24, 2015 at 8:17 AM, Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:
Le 21/08/2015 15:47, Yann Ylavic a écrit :
On Sun, Aug 16, 2015 at 12:05 AM, jaillet...@apache.org wrote:
+if ((i 1) || (i 1800)) {
Why a limit of 1800? Maybe the implicit INT_MAX is good enough.
Also the memcached may never close its connections by itself, or
always do, so -1 and 0 could also be interesting...
Obviously 0 should be allowed, but I don't see any reason for -1. What
difference would you make between the 2?
Hm, I thought that for apr_memcache_server_create (hence
apr_reslist_create), ttl=0 was always close (immediately) and -1 was
never close (infinite), but that's not the case (ttl=0 means never
close, and -1 is invalid).
Correct.
I don't know if memcached can be configured to always close the
connections when done (I guess so), but since the minimal TTL is 1
second, we could end up reusing connections closed remotely (without
recovering on error) in this case.
AFAIK, memcached can not be configured to close connections by itself.
Apparently all mpm are configured to ignore SIGPIPE, so
apr_socket_send() should just return the error and the logic in
apr_memcache should handle it.
I.e.:
ms_bad_conn(ms, conn);
apr_memcache_disable_server(mc, ms);
So why wouldn't we recover? If the connection is closed for whatever
reason, wouldn't the server be marked as DEAD?
Following calls to apr_memcache_find_server_hash_default would try it
again after 5 s.
So maybe our best option is to use ap_timeout_parameter_parse() to set
sconf-ttl, which would allow a TTL of 1 microsecond (min), and almost
no max (native 64bit apr_time_t)...
Regards,
Yann.
TTL value passed to apr_memcache_server_create is a apr_uint32_t.
It is then passed as-is to apr_reslist_create as a apr_interval_time_t
(i.e. apr_int64_t)
So, there *IS* a max value of 2^32 usec = 4294 s ~ 3600 s = 1h
Indeed, ap_timeout_parameter_parse() would be nice. This would allow TTL in
millisecond (ms). min is for minutes.
However having an upper limit of 4294 s (or 3600 in order to have a round
value) still makes sense to me.
CJ
Re: protocols and mod_h2 consolidation
Hi,
On 8/24/2015 9:29 AM, Stefan Eissing wrote:
I hope this works for everyone. The next weeks might be a good time to think
about it and propose any changes and correct my mistakes.
There are two things that go bump on my lowest non-eol version of MSVC.
h2_worker.c
.\h2_worker.c(113) : error C2440: 'function' : cannot convert from 'void
*(__cdecl *)(apr_thread_t *,void *)' to 'apr_thread_start_t'
.\h2_worker.c(113) : warning C4022: 'apr_thread_create' : pointer
mismatch for actual parameter 3
Casting execute to apr_thread_start_t (what apr_thread_create expects)
seems to quiet the compiler and FireFox seems to work with it.
h2_session.c
.\h2_session.c(1079) : error C2440: 'type cast' : cannot convert from
'int' to 'nghttp2_data_source'
.\h2_session.c(1081) : warning C4047: 'initializing' : 'int' differs in
levels of indirection from 'nghttp2_data_source_read_callback'
This cast to a union type, this MSVC version's docs on Unions has a note
in the comments mentioning;
We recommend that you do not use a union to cast data from one data
type to another because union members occupy the same address in memory.
There is no data-conversion support for unions. The results of
interchanging writes and reads between union members of different
types are unpredictable and depend on a variety of reasons.
They are evidently enforcing this. I just removed the cast and it builds
and Firefox seems to work.
Other nits of interest or not;
h2_stream_set.c
.\h2_stream_set.c(139) : warning C4028: formal parameter 2 different
from declaration
The function is prototyped as: h2_stream_set_match_fn *match
but in h2_stream_set.c it is: h2_stream_set_match_fn match
I get 2 different results for the $ENV{'SERVER_PROTOCOL'} in my perl
script depending on the machine. My server gives me HTTP/1.1 and
running locally on my build machine I get INCLUDED. Firefox says it is
HTTP/2.0 200 OK so both results in this $ENV seem incorrect. I'm not
sure why the difference as mod_h2 is configured same on both.
Regards,
Gregg
