Re: Named shared memory on macOS Monterey

2022-05-18 Thread Jim Jagielski
Yep. If I build APR w/ --enable-posix-shm all tests pass just fine. Otherwise I 
run into errors
where, when creating the shared memory segments, we run out (NOSPC)

> On May 18, 2022, at 8:15 AM, Eric Covener  wrote:
> 
> Is this what breaks the test framework with heartmonitor loaded? I've
> lost the errors, ended up commenting out the mod and re-running
> Makefiles.PL to get unblocked.
> 
> On Tue, May 17, 2022 at 3:26 PM Jim Jagielski  wrote:
>> 
>> Anyone else notice that the later version of macOS really prefer
>> that APR use posix for shared memory for both anon and name-based,
>> instead of posix for anon and sysv/ipc for name?
>> 
>> The issue seems to be that the kernel params are much lower than
>> previous versions as well as it being nigh-impossible to reset
>> those sysctl params on each boot, due to SIP.
>> 
>> Shouldn't we prefer posix over sysv in any case?
> 
> 
> 
> -- 
> Eric Covener
> cove...@gmail.com



Named shared memory on macOS Monterey

2022-05-17 Thread Jim Jagielski
Anyone else notice that the later version of macOS really prefer
that APR use posix for shared memory for both anon and name-based,
instead of posix for anon and sysv/ipc for name?

The issue seems to be that the kernel params are much lower than
previous versions as well as it being nigh-impossible to reset
those sysctl params on each boot, due to SIP.

Shouldn't we prefer posix over sysv in any case?


Re: svn commit: r1899390 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h

2022-04-01 Thread Jim Jagielski
It was added in anticipation of the capability to be folded in, and done so 
"now" so that it would;t require any API changes.

Unless it's actually breaking something, I'd vote to simply keep it

> On Apr 1, 2022, at 3:42 AM, jean-frederic clere  wrote:
> 
> On 01/04/2022 08:47, jean-frederic clere wrote:
>> On 31/03/2022 12:59, Ruediger Pluem wrote:
>>> 
>>> 
>>> On 3/31/22 12:34 PM, Stefan Eissing wrote:
 
 
> Am 31.03.2022 um 11:55 schrieb Ruediger Pluem :
> 
> 
> 
> On 3/31/22 11:11 AM, Ruediger Pluem wrote:
>> 
>> 
>> On 3/30/22 4:42 PM, jfcl...@apache.org wrote:
>>> Author: jfclere
>>> Date: Wed Mar 30 14:42:14 2022
>>> New Revision: 1899390
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1899390=rev
>>> Log:
>>> Add WorkerBalancerGrowth. To allow creation of workers
>>> to dynamically added balancers.
>>> 
>>> Modified:
>>> httpd/httpd/trunk/CHANGES
>>> httpd/httpd/trunk/modules/proxy/mod_proxy.c
>>> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>>> 
>>> Modified: httpd/httpd/trunk/CHANGES
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1899390=1899389=1899390=diff
>>>  
>>> ==
>>>  
>>> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
>>> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Mar 30 14:42:14 2022
>>> @@ -1,6 +1,10 @@
>>> -*- coding: utf-8 -*-
>>> Changes with Apache 2.5.1
>>> 
>>> + *) mod_proxy: Add WorkerBalancerGrowth to allow adding workers to
>>> + balancer created dynamically or via "empty" 
>>> + [Jean-Frederic Clere]
>> 
>> I am not sure why this is needed. You can already do this via
>> 
>> 
>> 
> 
> Or
> 
> 
> ProxySet growth=10
> 
 
 FYI: Travis trunk also fails almost completely. Does not seem to accept a 
 proxy configuration.
>>> 
>>> This is because the if
>>> 
>>> +  if (!ap_strchr_c(conf->p, ':'))
>>> +  return apr_pstrcat(cmd->pool, thiscmd->name,
>>> +  "> arguments are not supported for non url.",
>>> +  NULL);
>>> 
>>> should not return with an error, but just encapsulate the remainder of the 
>>> block. And I think the further
>>> return apr_pstrcat are also wrong.
>>> 
>>> But as said I am not sure about the purpose at all as you can already do, 
>>> what the patch should provide if I understand the patch
>>> correctly.
>> The purpose was to be able to add a balancer in the balancer-manager handle 
>> but that needs to pre-create the mutex and the slots for the workers.
>> While looking to that I noted that:
>> 
>> 
>> was doing nothing, the balancer is ignored, I should I revert the patch and 
>> add an error message if there is an empty entry like this one?
> 
> There is also the BalancerGrowth directive that does nothing else than 
> creating a memory slot for balancers we never add/create in the 
> balancer-manager, I am tempted to remove it...
> 
> Would it be better to add the missing logic? I have some pieces in 
> mod_proxy_cluster (https://github.com/modcluster/mod_proxy_cluster 
>  that could use the logic.
>>> 
>>> Regards
>>> 
>>> Rüdiger
> 
> 
> -- 
> Cheers
> 
> Jean-Frederic



Re: [VOTE] Release httpd-2.4.53-rc2 as httpd-2.4.53

2022-03-10 Thread Jim Jagielski



> On Mar 9, 2022, at 11:19 AM, Stefan Eissing  wrote:
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc2 as 2.4.53:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 

macOS 12.2.1 / Xcode 13.2.1
Ubuntu 20.04LTS



Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53

2022-03-09 Thread Jim Jagielski


> On Mar 9, 2022, at 8:58 AM, Yann Ylavic  wrote:
> 
> On Wed, Mar 9, 2022 at 2:45 PM Stefan Eissing  > wrote:
>> 
>>> Am 09.03.2022 um 14:25 schrieb Yann Ylavic :
>>> 
>>> On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung  wrote:
 
 - configure for APR in the dependency tarball still fails for me due to
 a bug in autoconf 2.71 used to create the configure script. That problem
 was already reported by me during another release vote. I replaced the
 changed three files in the bundled apr and apr-util with the earlier ones.
>>> 
>>> Does this depend on the RM's autoconf version?
>>> If so, Stefan could you downgrade to autoconf 2.69 on your system? I
>>> just did that on mine with:
>>> $ apt install autoconf=2.69-1
>>> 
>>> Sorry, I don't have a better idea..
>> 
>> I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
>> or will we just see the outcome of the rc2? (which is easy to make)
> 
> Thanks, I think a clean build on your local 2.4.x should do it:
> $ cd 2.4.x
> $ make distclean
> $ rm `find . -name configure`
> $ ./builconf
> $ ./config.nice
> $ make depend && make
> 

I've found make extraclean works a bit better



Re: backports

2022-03-08 Thread Jim Jagielski


> On Mar 8, 2022, at 7:58 AM, Graham Leggett  wrote:
> 
> 
> I would far rather the empty APLOGNO check was part of the build.
> 
> Vastly simpler.
> 

I agree w/ that...



Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53

2022-03-08 Thread Jim Jagielski



> On Mar 7, 2022, at 10:55 AM, Stefan Eissing  wrote:
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 

Tested:
  o macOS 12.2.1 w/ Xcode 13.2.1 / OpenSSL 1.1.1m
  o Ubuntu 20.04LTS / OpenSSL 1.1.1m



Re: backports

2022-03-07 Thread Jim Jagielski


> On Mar 7, 2022, at 6:28 AM, Graham Leggett  wrote:
> 
> On 07 Mar 2022, at 11:21, Stefan Eissing  > wrote:
> 
>> I'd really like, as a reviewer of backports, you can:
>> - see that it passes all our tests. No need to patch/compile/test locally.
> 
> “No need to patch/compile locally" is not a good idea - currently the travis 
> tests target Ubuntu only, and this is a practical limitation forced upon us 
> by the nature of the Travis service. I want to see reviewers try out the 
> patch on different architectures. I for example work on MacOS, but deploy to 
> Redhat, so those are my two environments. Others will have different 
> environments.
> 
> Our testing needs to be wide and diverse.

++1




Re: backports

2022-03-05 Thread Jim Jagielski



> On Mar 4, 2022, at 12:40 PM, Roy T. Fielding  wrote:
> 
>> On Mar 4, 2022, at 6:17 AM, Eric Covener  wrote:
>> 
>> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski  wrote:
>>> 
>>> A question: Would it be easier for all this if we moved to being Github 
>>> canon?
>> 
>> I think it is much more straightforward.  The original work, reviews
>> and travis results are all in the same place and nothing is copied
>> around.
>> I have had the same thought a few times this week. But I was hesitant
>> to reopen that thread/discussion because I'm pessimistic we can get
>> anywhere on it.
> 
> I think we are far beyond that point where staying with svn/bugzilla is 
> actively
> hurting the project for little or no benefit.
> 
> I'd +1 a switch just to get real issue management and PRs.
> 

That's where I was heading with this, so I'm an obvious +1 to switching to 
making
a Github-based workflow "official" for the PMC.

Re: backports

2022-03-04 Thread Jim Jagielski
A question: Would it be easier for all this if we moved to being Github canon?

> On Mar 4, 2022, at 5:08 AM, Stefan Eissing  wrote:
> 
> We should improve our backport procedure and provide guidance on how to use 
> it after the next release.
> 
> Post-mortem dbm backport:
> - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO()
> - the incomplete patch was voted on and accepted, as local tests do not have 
> the full CI checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools 
> available until the damage was done.
> 
> As noted in the related thread, backport proposal should really be PRs on 
> github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is 
> based on. In addition, we
> get the github UI for review and comments. Should be a win for all.
> 
> Kind Regards,
> Stefan
> 
> 



Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/

2022-03-03 Thread Jim Jagielski
Do we have a users guide for this specific implementation and setup? TIA!

Cheers


c99

2022-03-03 Thread Jim Jagielski
I'm guessing we all heard the news that Linux is switching
to c99 from c89.

Time for us to consider it as well?


Re: intent to make a release candidate on Monday

2022-03-03 Thread Jim Jagielski
All three promoted. I went ahead and merged the 'dbm' patch

> On Mar 3, 2022, at 4:37 AM, Stefan Eissing  wrote:
> 
> There are some important fixes pending release. Work does not appear to
> slow down in the foreseeable future, so I'd like us to make them available.
> 
> Looking at 2.4.x STATUS, there are 3 backport proposals lacking 1 vote:
> - dbm: Split the loading of a dbm driver
> - mod_proxy: Bump shared worker name to 384 chars. PR 53218
> - mod_http2: preserve the port number given in a HTTP/1.1
> 
> Maybe someone finds the time to look at those.
> 
> If you see something that definitely should be in the next
> release, but lack the time to make it ready for Monday, please
> let us know and we can discuss how we can help or adjust the
> schedule.
> 
> Kind Regards,
> 
> Stefan
> 
> 



Re: mod_tls as experimental module?

2021-11-24 Thread Jim Jagielski
Add it in :-)

> On Nov 24, 2021, at 4:46 AM, ste...@eissing.org wrote:
> 
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?
> 
> Curious,
> Stefan
> 
>> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org:
>> 
>> How would you feel about adding mod_tls 
>> (https://github.com/abetterinternet/mod_tls) as an experimental module to 
>> Apache httpd?
>> 
>> For people who have not followed that development:
>> - it is a TLS 1.2/1.3 implementation based on rustls, 
>> https://github.com/rustls/rustls
>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>> - it is itself written in C, linking all the Rust things from the rustls-ffi 
>> library
>> - it does not bring any Rust into our code base
>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>> (e.g. no client certificates now and not as tweakable - at least for now)
>> - it can be co-loaded and co-used with mod_ssl on different ports or 
>> front-/backend roles
>> - performance-wise, according to my plain vanilla tests, it is on par with 
>> mod_ssl
>> 
>> The decision to offer it downstream is of course then made by the distros, 
>> as usual with experimental modules. And if and how it is then used rests 
>> with the users. It is an offered alternative for people.
>> 
>> What would be the benefit to the project?
>> - we offer people an alternative. If they feel the memory safety that Rust 
>> offers is important to them, they can do it with Apache httpd for the TLS 
>> stack.
>> - we could see how people react to this and adapt our TLS offering 
>> accordingly. It being experimental, we remain free to change it. Or remove 
>> it again.
>> 
>> Organizational Things:
>> - the development was done by myself
>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the 
>> org behind Let's Encrypt, as part of they "memory safety" initiative 
>> (https://www.memorysafety.org)
>> 
>> 
>> Feedback appreciated,
>> 
>> Stefan
>> 
>> PS. On a more personal note:
>> The way this project turned out was a clean separation between C and Rust. 
>> The API offered by rustls-ffi is colored by Rust's immutability/borrowed 
>> memory concepts, but there is nothing Rust special the C code needs to do. 
>> It remains C code. It remains in our core competence.
>> 
>> Working with the rustls people has been nice and productive. The only thing 
>> I can report is that they come from the client TLS side and specific server 
>> needs require some explaining. There are things we can offer to them here.
>> 
>> There are a lot of political things going on right now around OpenSSL and I 
>> definitely want to stay out of that. Again, we can offer this without having 
>> to switch ourself. Even better, customers can use this without needing to 
>> switch completely, as it co-exists. I think that fits into the concepts our 
>> server is designed with.
>> 
>> Thanks for your time.
>> 
> 



Re: reporting the bytes read and transferred to the worker from the tunnel

2021-05-05 Thread Jim Jagielski
LGTM

> On May 5, 2021, at 5:59 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I have noted that when using websocket the bytes read and transfered by the 
> worker when using the tunnel are not taken in account.
> 
> I have a patch attached, for comments ;-)
> 
> Any better ideas how to fix that?
> 
> -- 
> Cheers
> 
> Jean-Frederic
> 



Apachecon

2021-03-19 Thread Jim Jagielski
Anyone submitting any httpd related proposals for AC2021?


Xcode 12

2020-10-29 Thread Jim Jagielski
Anyone hacking away on httpd and/or APR w/ Xcode 12? On my system at least it 
is throwing errors about -Werror,-Wimplicit-function-declaration, and not 
enabling IPv6:

checking if APR supports IPv6... no -- no working getaddrinfo

also likely due to an error when compiling because of stdlib.h not being 
included...

Warning: Xcode12 breaks apr* and httpd

2020-09-18 Thread Jim Jagielski
The upgrade from Xcode11 -> Xcode12 has been reported to break builds for APR 
and httpd... Issues seem to be some sort of forced C99 compliance and not 
discovering IPv6 capability.

I'm not upgrading anytime soon so no idea how bad it is.

Re: Changing the httpd security process

2020-08-17 Thread Jim Jagielski
++1. I was never quite happy with this process, but it seemed like there was a 
lot of support for this kind of treatment. 

> On Aug 17, 2020, at 7:08 AM, Joe Orton  wrote:
> 
> 
> This roughly reverts the httpd process to what we used prior to adopting 
> the Tomcat-esque policy for the whole ASF.  We would have to document 
> this and possibly need it approved by the ASF security team.
> 



Re: Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45

2020-07-31 Thread Jim Jagielski
+1

> On Jul 31, 2020, at 9:41 AM, Eric Covener  wrote:
> 
> On Fri, Jul 31, 2020 at 9:37 AM Rainer Jung  wrote:
>> 
>> Since there wasn't yet any reaction to Daniel's question: Is anybody
>> right now working on more warnings fixes for Windows?
>> 
> 
> Not me. I don't think we should wait on them.
> 
>> The most prominent one (missing APLOGNo number = missing macro argument)
>> IMHO was already fixed by Christophe in r1880438. Anything else worth
>> waiting for or are we (is Daniel) good to go for 2.4.46?
> 
> Good to go from my POV.
> 
>> Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing.
> 
> +1



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Jim Jagielski



> On Jul 30, 2020, at 5:55 AM, Christophe JAILLET 
>  wrote:
> 
> I wouldn't say it is a show stopper, but I thought that we had a travis job 
> for that.
> Apparently, it is on trunk only (see r1879370 which is not backported, maybe 
> on purpose)
> 

I agree that it's not a show-stopper but it is something that seems easy to fix 
and, considering that (1) we want to release the best possible version as we 
can and (2) there is quite a bit of time between releases, I wouldn't be 
opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.



Re: [VOTE] Release httpd-2.4.44

2020-07-29 Thread Jim Jagielski
I'll hold off testing and voting until we hear from the RM on whether this 
release is DOA or not...

> On Jul 29, 2020, at 8:02 AM, Stefan Eissing  
> wrote:
> 
> -1.
> 
> I have to apologise. I missed an important change in HTTP/2 that I like to 
> get in the release. This is about removing support for an abandoned http-wg 
> draft that we do not want any longer in our server.
> 
> Will do the changes right away and let you know when I am done.
> 
> Again, sorry to everyone for the wasted cycles. :(
> 
> - Stefan
> 
>> Am 28.07.2020 um 19:51 schrieb Daniel Ruggeri :
>> 
>> Hi, all;
>>   Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.44:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> 
>> The computed digests of the tarball up for vote are:
>> sha1: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
>> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
>> *httpd-2.4.44.tar.gz
>> sha512:
>> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
>> *httpd-2.4.44.tar.gz
>> 
>> The SVN tag is '2.4.44' at r1880378.
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> 
> 



Re: NOTICE: Intent to T late this week

2020-07-23 Thread Jim Jagielski
Sure. Go ahead. +1

> On Jul 22, 2020, at 7:32 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.
> -- 
> Daniel Ruggeri



Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

2020-07-01 Thread Jim Jagielski


> On Jun 29, 2020, at 10:27 AM, Graham Leggett  wrote:
> 
> On 29 Jun 2020, at 14:49, Yann Ylavic  > wrote:
> 
>>> Yes we can and should (but in separate commits).
>>> 
>>> I have my eye on the r->proxyreq flag, we can pack this into the binary 
>>> notes too, values don’t need to be one bit wide.
>> 
>> Actually I was thinking the other way around, have the new "unsigned
>> int strong_etag:1" bitfield rather than changing the existing ones...
>> Why adding complexity with bit(s) macros while bitfields exist?
> 
> The problem with bitfields in the public APIs is that they’re not binary 
> compatible across compilers. While it is very rare that a module will be 
> built with a different compiler than httpd was, it’s still theoretically 
> possible, and we should probably avoid it. Bitfields aren’t a problem for 
> in-module or in-core code.

++1



Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Jim Jagielski
Works for me.

> On May 29, 2020, at 3:30 PM, Ruediger Pluem  wrote:
> 
> Reviewing our backport process I noticed that in many cases a clean merge via 
> svn merge fails due to conflicts in CHANGES. While
> these are easy to solve it puts IMHO unnecessary extra work on the backport 
> process, both for reviewing and for actually doing the
> backport. How about if we change the way we document changes the following 
> way:
> 
> 1. We create a changes-fragments directory (name to be determined) at the top 
> level.
> 2. For each release we create a subdirectory such that we end up with the 
> following structure:
> 
>   changes-fragments/
> 2.4.41/
> 2.4.42/
> 2.4.43/
> 2.4.44/
> 
> 3. Each directory contains the changes for each release and each change entry 
> is a single file.
> 4. We have a script that builds our current CHANGES file from the content in 
> changes-fragments directories with the help of
>   a template or at least some sort of header / footer that is static.
> 5. This script can be called either manually and we commit the resulting 
> CHANGES file as we like just like the x-forms commits
>   for documentation plus this script is called by the release scripts from 
> Daniel as part of the preparation of rolling a
>   release.
> 
> 
> Regards
> 
> Rüdiger



Re: Building from svn on MacOS

2020-04-15 Thread Jim Jagielski
I always have svn co of apr and apr-util in srclib when I build from SVN


Re: svn commit: r1876511 - /httpd/httpd/trunk/modules/core/mod_watchdog.c

2020-04-15 Thread Jim Jagielski
very, very elegant.

> On Apr 14, 2020, at 8:37 AM, jor...@apache.org wrote:
> 
> Author: jorton
> Date: Tue Apr 14 12:37:17 2020
> New Revision: 1876511
> 
> URL: http://svn.apache.org/viewvc?rev=1876511=rev
> Log:
> * modules/core/mod_watchdog.c: Switch to simpler logic to avoid the
>  thread cleanup running before the thread has started, avoiding
>  mutex operations which both have undefined behaviour:
> 
>  a) double-locking an UNNESTED (non-recursive) mutex twice in the parent
>  b) unlocking a mutex in the spawned thread which was locked by the parent
> 
>  (wd_startup, wd_worker_cleanup, wd_worker): Use a boolean to ensure
>  the cleanup does nothing if the thread wasn't started, drop the mutex.
> 
> Modified:
>httpd/httpd/trunk/modules/core/mod_watchdog.c
> 
> Modified: httpd/httpd/trunk/modules/core/mod_watchdog.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/core/mod_watchdog.c?rev=1876511=1876510=1876511=diff
> ==
> --- httpd/httpd/trunk/modules/core/mod_watchdog.c (original)
> +++ httpd/httpd/trunk/modules/core/mod_watchdog.c Tue Apr 14 12:37:17 2020
> @@ -24,6 +24,8 @@
> #include "http_core.h"
> #include "util_mutex.h"
> 
> +#include "apr_atomic.h"
> +
> #define AP_WATCHDOG_PGROUP"watchdog"
> #define AP_WATCHDOG_PVERSION  "parent"
> #define AP_WATCHDOG_CVERSION  "child"
> @@ -43,7 +45,7 @@ struct watchdog_list_t
> 
> struct ap_watchdog_t
> {
> -apr_thread_mutex_t   *startup;
> +apr_uint32_t  thread_started; /* set to 1 once thread running */
> apr_proc_mutex_t *mutex;
> const char   *name;
> watchdog_list_t  *callbacks;
> @@ -74,6 +76,10 @@ static apr_status_t wd_worker_cleanup(vo
> apr_status_t rv;
> ap_watchdog_t *w = (ap_watchdog_t *)data;
> 
> +/* Do nothing if the thread wasn't started. */
> +if (apr_atomic_read32(>thread_started) != 1)
> +return APR_SUCCESS;
> +
> if (w->is_running) {
> watchdog_list_t *wl = w->callbacks;
> while (wl) {
> @@ -110,7 +116,8 @@ static void* APR_THREAD_FUNC wd_worker(a
> w->pool = apr_thread_pool_get(thread);
> w->is_running = 1;
> 
> -apr_thread_mutex_unlock(w->startup);
> +apr_atomic_set32(>thread_started, 1); /* thread started */
> +
> if (w->mutex) {
> while (w->is_running) {
> if (ap_mpm_query(AP_MPMQ_MPM_STATE, _s) != APR_SUCCESS) {
> @@ -264,10 +271,7 @@ static apr_status_t wd_startup(ap_watchd
> {
> apr_status_t rc;
> 
> -/* Create thread startup mutex */
> -rc = apr_thread_mutex_create(>startup, APR_THREAD_MUTEX_UNNESTED, p);
> -if (rc != APR_SUCCESS)
> -return rc;
> +apr_atomic_set32(>thread_started, 0);
> 
> if (w->singleton) {
> /* Initialize singleton mutex in child */
> @@ -277,22 +281,12 @@ static apr_status_t wd_startup(ap_watchd
> return rc;
> }
> 
> -/* This mutex fixes problems with a fast start/fast end, where the pool
> - * cleanup was being invoked before the thread completely spawned.
> - */
> -apr_thread_mutex_lock(w->startup);
> -apr_pool_pre_cleanup_register(p, w, wd_worker_cleanup);
> -
> /* Start the newly created watchdog */
> rc = apr_thread_create(>thread, NULL, wd_worker, w, p);
> -if (rc) {
> -apr_pool_cleanup_kill(p, w, wd_worker_cleanup);
> +if (rc == APR_SUCCESS) {
> +apr_pool_pre_cleanup_register(p, w, wd_worker_cleanup);
> }
> 
> -apr_thread_mutex_lock(w->startup);
> -apr_thread_mutex_unlock(w->startup);
> -apr_thread_mutex_destroy(w->startup);
> -
> return rc;
> }
> 
> 
> 



Re: [VOTE] Release httpd-2.4.43

2020-03-27 Thread Jim Jagielski
+1:
   o macOS 10.14.6, Xcode 11.3.1 (Event MPM): No regressions - Perl test 
framework
   o CentOS 6.10, 64bit (Event and Worker MPM): No regressions - Perl test 
framework
   o CentOS 7.7, 64bit (Event and Worker MPM): No regressions - Perl test 
framework

> On Mar 26, 2020, at 10:50 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.43:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
> *httpd-2.4.43.tar.gz
> sha512:
> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
> *httpd-2.4.43.tar.gz
> 
> The SVN tag is '2.4.43' at r1875715.
> 
> -- 
> Daniel Ruggeri
> 



Re: [VOTE] Release httpd-2.4.42

2020-03-23 Thread Jim Jagielski
Based on this, I change my vote to -1

> On Mar 19, 2020, at 11:19 AM, Eric Covener  wrote:
> 
> On Thu, Mar 19, 2020 at 10:45 AM Daniel Ruggeri  > wrote:
>> 
>> Hi, all;
>>Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> 
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.42:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> 
>> The computed digests of the tarball up for vote are:
>> sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
>> sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
>> *httpd-2.4.42.tar.gz
>> sha512:
>> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
>>  *httpd-2.4.42.tar.gz
>> 
>> The SVN tag is '2.4.42' at r1875427.
>> 
> 
> Looks like r1874288 broke my basic apxs usage w/o DESTDIR in use.
> Seems broken in my trunk sandbox too.



Re: async filters still borked (was Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis)

2020-03-20 Thread Jim Jagielski
+1 from me.

> On Mar 20, 2020, at 9:46 AM, Joe Orton  wrote:
> 
> On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote:
>> On 3/4/20 9:23 AM, jor...@apache.org wrote:
>>> Author: jorton
>>> Date: Wed Mar  4 08:23:55 2020
>>> New Revision: 1874775
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1874775=rev
>>> Log:
>>> Update docs. The expr_string.t failure has not been seen since 
>>> the workaround was added AFAICT.  The async filter bug
>>> is still breaking the tests regularly. [skip ci].
>> 
>> Anyone found time to check
>> 
>> https://github.com/apache/httpd/pull/88
>> 
>> regarding the async filter bug?
> 
> [crickets]
> 
> We are two months on since discussing this first.  It seems quite 
> worrying that the async filters stuff was introduced with apparently 
> nasty bugs and yet is already bitrotting on trunk with not enough people 
> to review and fix it.  Can we move the code to a branch until it is 
> ready?
> 
> Regards, Joe
> 



Re: [VOTE] Release httpd-2.4.42

2020-03-20 Thread Jim Jagielski
+1: macOS 10.14.6, Xcode 11.3.1: No regressions - Perl test framework

Will try to test on CentOS 6-8 today

> On Mar 19, 2020, at 10:45 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.42:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
> sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed 
> *httpd-2.4.42.tar.gz
> sha512: 
> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
>  *httpd-2.4.42.tar.gz
> 
> The SVN tag is '2.4.42' at r1875427.
> 
> -- 
> Daniel Ruggeri



Netcraft

2020-02-21 Thread Jim Jagielski
Wow. Was Netcraft actually somewhat kind to Apache httpd? They actually 
admitted some areas where httpd is doing better, and still does better, 
market-share wise, than nginx.

Re: Add an entry in CHANGES file for Travis CI testing

2020-02-13 Thread Jim Jagielski
++1

> On Feb 11, 2020, at 12:43 PM, Mike Rumph  wrote:
> 
> With the talk of releasing 2.4.42, I was thinking that it might be a good 
> idea to add some mention of the Travis CI testing that was added in this 
> release.
> Perhaps something in the CHANGES file that gives a summary of the results 
> achieved by this.
> This could include a list of the various platforms and architectures that 
> were tested.
> 
> Mike



Time for 2.4.42?

2020-02-11 Thread Jim Jagielski
Seems like a good time to propose a release... I can RM if desired.


Your Apache HTTPD story

2020-01-22 Thread Jim Jagielski
The CFP (Call For Papers) for ApacheCon NA 2020 is now open, and one major 
topic will be regarding the one project that started it all: Apache httpd.

I am coordinating the Apache httpd track, and I am encouraging not only 
developers but more importantly USERS of the Apache web server to submit a talk 
or talks about how YOU use Apache; share your knowledge, share your experience!

Check out the following link and, if you feel so inclined, Email me a copy of 
your proposal:

https://apachecon.com/acna2020/cfp.html

Cheers!

Re: Time for httpd 2.6.x?

2019-11-03 Thread Jim Jagielski


> On Nov 1, 2019, at 11:59 AM, Luca Toscano  wrote:
> 
> Il giorno mar 29 ott 2019 alle ore 18:31 Graham Leggett
> mailto:minf...@sharp.fm>> ha scritto:
>> 
>> On 29 Oct 2019, at 15:51, Jim Jagielski  wrote:
>> 
>>> My only question regards workflow w/ trunk. Right now, I think we all agree 
>>> that there are codepaths and features in trunk that are not as stable as we 
>>> would like. Which is fine... trunk is CTR. But we do need some way to vet 
>>> those changes (ie, we need to "R" all those "C"s). Some will be accepted, 
>>> others not. Into what branch do those accepted go? And for the things not 
>>> accepted for eventually inclusion in 2.5/2.6, do they get removed from 
>>> trunk? Do they stay in trunk?
>> 
>> As I recall from v2.4, we branched from trunk, and then we removed anything 
>> we deemed “not ready” from the branch. “not ready” had reasonably simple 
>> criteria, like “not documented yet”.
>> 
>>> So it seems to me that we need to branch trunk into 2.5.x and "clean up" 
>>> that branch (items 1-5) and leave trunk alone.
>> 
>> +1.
>> 
>> Let’s get a 2.5 out there, and let people bash on it.
> 
> If this was the previous way of doing things and it worked, +1 as
> well. Is there anybody willing to start this process?

I don't want to start any process w/o more consensus about going forward... In 
particular, branching 2.5.x from trunk...



Re: Time for httpd 2.6.x?

2019-10-29 Thread Jim Jagielski


> On Oct 29, 2019, at 9:36 AM, Eric Covener  wrote:
> 
> On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano  > wrote:
>> 
>> Hi everybody,
>> 
>> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic
>>  ha scritto:
>>> 
>>> So how about:
>>> 0. github workflow? meanwhile...
>>> 1. compare trunk/2.4.x (inventory)
>>> 2. discuss unused/deprecated in trunk to cleanup
>>> 3. address STALLED entries in trunk if it's not for compatibily reasons
>>> 4. do API/ABI breaking changes in trunk
>>> 5. improve trunk w/ things we want in 2.6.x (the real part!)
>>> 6. trunk => 2.6.x
>>> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
>>> 8. 2.6.alpha/beta/gamma/rc/whatever
>>> 9. fix in trunk and backport to 2.6.x
>>> 10. if not good enough goto 8.
>>> 11. 2.6.0
>>> 12+ usual release cycle
>> 
>> The above proposal from Yann seems to be something that could work for
>> everybody as far as I can tell, what do you think? Do we need an
>> explicit vote thread?
> 
> Nit: Not using 2.5.x is a departure from convention.
> 
> I don't think a wholesale vote is needed for #1-5. I am skeptical
> there is interest/velocity in getting past #2.
> By the time we're at #8, I would say a vote is warranted as an
> additional branch has a cost.

My only question regards workflow w/ trunk. Right now, I think we all agree 
that there are codepaths and features in trunk that are not as stable as we 
would like. Which is fine... trunk is CTR. But we do need some way to vet those 
changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. 
Into what branch do those accepted go? And for the things not accepted for 
eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay 
in trunk?

So it seems to me that we need to branch trunk into 2.5.x and "clean up" that 
branch (items 1-5) and leave trunk alone.

Just my 2c

Re: svn commit: r1860166 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ modules/http2/ modules/proxy/ server/

2019-10-29 Thread Jim Jagielski
Yikes! How can we test for that via the Perl test framework?

> On Oct 29, 2019, at 9:45 AM, Rainer Jung  wrote:
> 
> Aha, and this is due to the fact, that r1656259 "mod_proxy_http: don't 
> connect or reuse backend before prefetching request body." or parts of it was 
> backported from trunk to 2.4 as part of r1860166.
> 
> So I think (not yet verified), that the same problems applies to trunk since 
> r1656259 in February 2015 :(
> 
> Regards,
> 
> Rainer
> 
> Am 29.10.2019 um 14:21 schrieb Rainer Jung:
>> The reason why this fails now is that we prefetch in 2.4.41 the request body 
>> before doing the connection check to the backend. In 2.4.39 we did that 
>> after doing the check, so the body was still there when doing the final 
>> request sending.
>> 2.4.39:
>> In proxy_http_handler():
>> - ap_proxy_determine_connection()
>> - ap_proxy_check_connection()
>> - optionally ap_proxy_connect_backend() which might fail.
>> - ap_proxy_connection_create_ex()
>> - ap_proxy_http_request() which does prefetch late!
>> 2.4.41:
>> In proxy_http_handler():
>> - ap_proxy_determine_connection()
>> - early ap_proxy_http_prefetch() which does the prefetch!
>> - optionally again ap_proxy_determine_connection()
>> - ap_proxy_check_connection()
>> - optionally ap_proxy_connect_backend() which might fail.
>> - ap_proxy_connection_create_ex()
>> - ap_proxy_http_request()
>> So we either need to remember the prefetch result for later retries or 
>> switch back to the old order.
>> Regards,
>> Rainer
>> Am 29.10.2019 um 12:46 schrieb Rainer Jung:
>>> This happens in the case of a small body. We read the body into 
>>> req->input_brigade in ap_proxy_http_prefetch() before trying the first 
>>> node, but then loose it on the second node, because we use another req and 
>>> thus also another req->input_brigade then.
>>> 
>>> Not sure, how we could best save the read input_brigade for the second 
>>> attempt after failover. Will try some experiments.
>>> 
>>> If you try to reproduce yourself, make sure you use a small POST (here: 30 
>>> bytes) and also exclude /favicon.ico from forwarding when using a browser. 
>>> Otherwise some of the failovers will be triggered by favicon.ico and you'll 
>>> not notice the problem in the POST request:
>>> 
>>> ProxyPass /favicon.ico !
>>> 
>>> Regards,
>>> 
>>> Rainer
>>> 
>>> Am 29.10.2019 um 11:15 schrieb Rainer Jung:
 A first heads-up: it seems this commit broke failover for POST requests. 
 Most (or all?) of the times a balancer failover happens for a POST 
 request, the request send to the failover node has a Content-Length of "0" 
 instead of the real content length.
 
 I use a trivial setup like this:
 
 
ProxySet lbmethod=byrequests
BalancerMember http://localhost:5680
BalancerMember http://localhost:5681
 
 
 ProxyPass / balancer://backends/
 
 where one backend node is up and the second node is down.
 
 I will investigate further.
 
 Regards,
 
 Rainer
> 
> -- 
> kippdata
> informationstechnologie GmbH   Tel: 0228 98549 -0
> Bornheimer Str. 33aFax: 0228 98549 -50
> 53111 Bonn www.kippdata.de
> 
> HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
> Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann



Re: Time for httpd 2.6.x?

2019-10-25 Thread Jim Jagielski



> On Oct 25, 2019, at 6:59 AM, Graham Leggett  wrote:
> 
> On 24 Oct 2019, at 14:14, Jim Jagielski  wrote:
> 
>> Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports 
>> from trunk have maintained the 2.4.x ABI backwards compatibility.
>> 
>> So I would propose that if we do the below, which I am fine w/ BTW, that the 
>> 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI 
>> changes.
>> 
>> Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, 
>> untested and wonky stuff that I would be somewhat worried about releasing... 
>> So that's why I like basing 2.6.x off of 2.4.x rather than trunk.
> 
> I would rather we stick to our existing practise of branching off trunk, then 
> evaluating what we want in 2.6 and explicitly removing what we don't want.
> 
> This is what we did when 2.4 came out, and it worked well.
> 

I'm fine w/ whatever we all decide.



Re: Time for httpd 2.6.x?

2019-10-24 Thread Jim Jagielski
Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from 
trunk have maintained the 2.4.x ABI backwards compatibility.

So I would propose that if we do the below, which I am fine w/ BTW, that the 
1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI 
changes.

Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, 
untested and wonky stuff that I would be somewhat worried about releasing... So 
that's why I like basing 2.6.x off of 2.4.x rather than trunk.

FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't 
see the attraction or need to revisit it.

> On Oct 23, 2019, at 9:02 AM, Luca Toscano  wrote:
> 
> Thanks a lot for all the answers, waiting for more people to chime in!
> What I personally like (at a very high level):
> 
> 1) create a 2.6.x branch from 2.4.x and start backporting commits from
> trunk (with votes etc..), up to the point that we feel 2.6.0 GA is
> ready, then follow the regular release process. Christophe's tool for
> visualizing diffs between trunk and 2.4.x could be really handy and
> helpful.
> 2) Leave trunk as it is, and consider fixing the issues currently outstanding.
> 3) Use STATUS to decide what modules/code is to be deprecated.
> 4) Decide when 2.4.x should be considered EOLed in the future.
> 5) Decide how/when to bump minor versions in the future, so anybody
> adding/contributing code to httpd will have a very high level
> expectation of when some code can be released. IIRC during the past
> threads it was mentioned that a lot of people contributed with good
> code still sitting in trunk due to backporting issues to 2.4.x
> (breaking ABI etc..). It is not really fair and it surely drives away
> contributors that aim to work on major changes to httpd.
> 
> Luca
> 
> 
> Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing
>  ha scritto:
>> 
>> Hi All,
>> 
>> I agree with CJ here.
>> 
>> As I said in the past, my idea would be to:
>> - trunk -> trunk-old,
>> - copy 2.4.x -> trunk
>> - any feature to bring from trunk-old to the new trunk needs a champion, 
>> e.g. someone who does the work (porting and test cases)
>> 
>> To some, that looks like we do not honour past work from people (that was 
>> one of the arguments brought forward last time). But it is not only about 
>> honour of devs, but also about the sweat and tears of the maintainers during 
>> 2.6.x releases. If a feature does not find someone to merge from one branch 
>> to another, how could we support this feature in a release? What do the 5-6 
>> people who handle 99% of all PRs think about this?
>> 
>> As to the list of things to abandon from 2.4.x, we could handle those like 
>> the backport voting in STATUS.
>> 
>> Cheers, Stefan
>> 
>>> Am 23.10.2019 um 10:18 schrieb Christophe JAILLET 
>>> :
>>> 
>>> Hi Luco,
>>> 
>>> I've nothing against a 2.6.x branch.
>>> My only fear is things in trunk that is incomplete and or not enough 
>>> reviewed.
>>> In other words, our backport mechanism with at least 3 votes is safeguard 
>>> for me.
>>> 
>>> My personal point of view is that 2.6.x should be built with backports from 
>>> trunk, just as done actually for 2.4.x.
>>> But I know it is not the point of view of many others that consider that 
>>> what is in trunk is (or should be) functional, reviewed and tested.
>>> Anyway, even if some things are less reviewed, alpha, beta and GA are there 
>>> to give others the opportunity to test and report issues, so I is maybe not 
>>> that bad to go this way, after all.
>>> 
>>> 
>>> If we want to go on the 2.6 way, maybe we could open some discussion:
>>> 
>>>  - should we deprecate or remove some 2.4.x functionalities or modules? 
>>> (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low 
>>> activity, ...)
>>> 
>>>  - should we remove things in trunk that are incomplete or lack consensus: 
>>> (this illustrate my fears above)
>>>- mod_serf and libserf support? : serf project looks mostly inactive 
>>> nowadays, mod_sef have no documentation
>>>- pcre2 support? (comments in commits or code say that it is 
>>> incomplete and that there is performance or memory management issues)
>>>- things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED
>>> 
>>>  - should we increase the APR minimum version and cleanup existing code 
>>> accordingly? (i.e. switch from some ap_ to apr_ functions)
>>> 
>>>  - we could start to write a "new_features_2_6.html" in order to list new 
>>> goodies and incompatibilities and changed behavior
>>> 
>>> 
>>> just my 2c.
>>> 
>>> CJ
>>> 
>>> Le 23/10/2019 à 08:28, Luca Toscano a écrit :
 Not even a comment? :)
 
 Luca
 
 Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano
  ha scritto:
> Hi everybody,
> 
> in trunk's STATUS there are a lot of suggestions about things to
> improve/change for 2.6.x. There have been discussions during the past
> couple of years about 

Re: svn commit: r1868456 - /httpd/httpd/branches/2.4.x/STATUS

2019-10-14 Thread Jim Jagielski



> On Oct 14, 2019, at 3:14 PM, jaillet...@apache.org wrote:
> 
> Author: jailletc36
> Date: Mon Oct 14 19:14:04 2019
> New Revision: 1868456
> 
> URL: http://svn.apache.org/viewvc?rev=1868456=rev
> Log:
> Add a note
> 
> Modified:
>httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1868456=1868455=1868456=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 14 19:14:04 2019
> @@ -178,6 +178,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   trunk patch: http://svn.apache.org/r1867183
>   2.4.x patch: svn merge -c 1867183 ^/httpd/httpd/trunk .
>   +1: jim
> +  jailletc36: -0
> +  I don't think that the #pragma black magic is of any help 
> with GCC 
> +  and jim seems to still have problem with clang and 
> comments with //.
> +  See discussion at:
> +  
> https://lists.apache.org/thread.html/628cc54a1a345cb773d8e1be0639f8e75d2b481cf89232051c83b787@%3Cdev.httpd.apache.org%3E


The problem still exists because this is NOT back ported yet. With this back 
port, the problem goes away.

Re: httpd 2.4 and maintainer-mode

2019-10-14 Thread Jim Jagielski
Yeah, this seems clang specific...

> On Oct 14, 2019, at 2:48 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> 
> Le 14/10/2019 à 17:15, Jim Jagielski a écrit :
>> 
>>> On Oct 10, 2019, at 2:49 PM, Marion & Christophe JAILLET 
>>>  wrote:
>>> 
>>> I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation in 
>>> .h files included from "outside".
>> So you aren't using Xcode and clang?
> 
> 
> No, just some comand line tools, some scripts, gcc and Geany as an IDE.
> 
> CJ
> 



Re: httpd 2.4 and maintainer-mode

2019-10-14 Thread Jim Jagielski



> On Oct 10, 2019, at 2:49 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation in 
> .h files included from "outside".
> 

So you aren't using Xcode and clang?

Re: httpd 2.4 and maintainer-mode

2019-10-10 Thread Jim Jagielski
And this is with maintainer-mode? I'm wondering why your setup is either OK w/ 
the C++ style comments or maybe Homebrew changes the comment style??

> On Oct 10, 2019, at 8:33 AM, Stefan Eissing  
> wrote:
> 
> When will I learn to read mails completely?
> 
> - Ok, proxy-html is not build by default, which explains the happiness due to 
> ignorance. 
> - Once enabled, it does not find libxml2 (I think MacOS Vista removed it)
> - brew reinstall libxml2
> - configure   --with-libxml2=/usr/local/opt/libxml2
> 
> and it builds on my machine.
> 
> - Stefan
> 
>> Am 10.10.2019 um 14:10 schrieb Jim Jagielski :
>> 
>> I am using MacPorts libxml2. But the issue seems to be w/ libxml2 itself; it 
>> is the package that uses the '//' comment style. Where does your build grab 
>> its xml2 stuff from?
>> 
>>> On Oct 10, 2019, at 3:58 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> Compiling trunk and 2.4.x under MacOS Vista, no issues. Some homebrew 
>>> install?
>>> 
>>>> Am 09.10.2019 um 19:04 schrieb Marion & Christophe JAILLET 
>>>> :
>>>> 
>>>> Hi Jim,
>>>> 
>>>> I always compile (and test) with --enable-maintainer-mode.
>>>> 
>>>> I've just updated my 2.4 branch / make clean / make, and there is nothing 
>>>> special.
>>>> 
>>>> Any specific issue?
>>>> 
>>>> CJ
>>>> 
>>>> 
>>>> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>>>>> Anyone else trying to build HEAD of httpd-2.4 with 
>>>>> --enable-maintainer-mode?
>>>>> 
>>> 
>> 
> 



Re: httpd 2.4 and maintainer-mode

2019-10-10 Thread Jim Jagielski
as mentioned, this is httpd-2.4... I was curious why I seem to be the only one 
whom this hits.

> On Oct 10, 2019, at 9:43 AM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 9, 2019 at 3:42 PM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> Just the issues w/ libxml comments:
> 
> In file included from mod_xml2enc.c:38:
> In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
> /usr/local/include/unicode/ucnv.h:1:1: error: // comments are not allowed in 
> this language [-Werror,-Wcomment]
> // Copyright (C) 2016 and later: Unicode, Inc. and others.
> 
> Jim, are you missing 
> http://svn.apache.org/viewvc?view=revision=1867183 
> <http://svn.apache.org/viewvc?view=revision=1867183>
> which you had already fixed the quirk on trunk/?  Seems that clang is being a 
> bit opaque
> about it's identity and confounding the pragmas wrapping our libxml2.h 
> includes.
> 



Re: httpd 2.4 and maintainer-mode

2019-10-10 Thread Jim Jagielski
I am using MacPorts libxml2. But the issue seems to be w/ libxml2 itself; it is 
the package that uses the '//' comment style. Where does your build grab its 
xml2 stuff from?

> On Oct 10, 2019, at 3:58 AM, Stefan Eissing  
> wrote:
> 
> Compiling trunk and 2.4.x under MacOS Vista, no issues. Some homebrew install?
> 
>> Am 09.10.2019 um 19:04 schrieb Marion & Christophe JAILLET 
>> :
>> 
>> Hi Jim,
>> 
>> I always compile (and test) with --enable-maintainer-mode.
>> 
>> I've just updated my 2.4 branch / make clean / make, and there is nothing 
>> special.
>> 
>> Any specific issue?
>> 
>> CJ
>> 
>> 
>> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>>> Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?
>>> 
> 



Re: httpd 2.4 and maintainer-mode

2019-10-09 Thread Jim Jagielski
 included from /usr/local/include/libxml2/libxml/encoding.h:31:
/usr/local/include/unicode/ucnv.h:1:1: error: // comments are not allowed in 
this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
/usr/local/include/libxml2/unicode/ucnv_err.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
/usr/local/include/libxml2/unicode/utypes.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
/usr/local/include/libxml2/unicode/umachine.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
/usr/local/include/libxml2/unicode/ptypes.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
In file included from /usr/local/include/libxml2/unicode/ptypes.h:52:
/usr/local/include/libxml2/unicode/platform.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^
In file included from mod_proxy_html.c:44:
In file included from /usr/local/include/libxml2/libxml/HTMLparser.h:16:
In file included from /usr/local/include/libxml2/libxml/parser.h:810:
In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
In file included from /usr/local/include/unicode/ucnv.h:52:
In file included from /usr/local/include/libxml2/unicode/ucnv_err.h:88:
In file included from /usr/local/include/libxml2/unicode/utypes.h:38:
In file included from /usr/local/include/libxml2/unicode/umachine.h:46:
In file included from /usr/local/include/libxml2/unicode/ptypes.h:52:
In file included from /usr/local/include/libxml2/unicode/platform.h:24:
/usr/local/include/libxml2/unicode/uconfig.h:1:1: error: // comments are not 
allowed in this language [-Werror,-Wcomment]
// Copyright (C) 2016 and later: Unicode, Inc. and others.
^


> On Oct 9, 2019, at 1:04 PM, Marion & Christophe JAILLET 
>  wrote:
> 
> Hi Jim,
> 
> I always compile (and test) with --enable-maintainer-mode.
> 
> I've just updated my 2.4 branch / make clean / make, and there is nothing 
> special.
> 
> Any specific issue?
> 
> CJ
> 
> 
> Le 09/10/2019 à 15:33, Jim Jagielski a écrit :
>> Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?
>> 



httpd 2.4 and maintainer-mode

2019-10-09 Thread Jim Jagielski
Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?


ACNA20 and Apache https's 25th anniversary

2019-10-06 Thread Jim Jagielski
Next year will be httpd's 25th anniversary. I think it would be great if the 
web server PMC would commit to having a httpd track at ACNA20...

Anyone else interested? We'd need about 6-7 talks to fill the track.

Migrate to git?

2019-10-05 Thread Jim Jagielski
Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!

Problem w/ Revision 1864435

2019-09-19 Thread Jim Jagielski
This breaks building on macOS:

Making all in filters
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_data.la mod_data.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_ratelimit.la mod_ratelimit.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_reqtimeout.la mod_reqtimeout.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_ext_filter.la mod_ext_filter.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_request.la mod_request.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_include.la mod_include.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_filter.la mod_filter.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_reflector.la mod_reflector.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_substitute.la mod_substitute.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_sed.la mod_sed.lo sed0.lo sed1.lo 
regexp.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall 
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89 
-Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
-Wunused -g -O0 -static  -o libmod_charset_lite.la mod_charset_lite.lo
/Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent --mode=link 
gcc -I/usr/local/include/libxml2 

Suggestions

2019-09-06 Thread Jim Jagielski
Any suggestions or recommendation for features, capabilities, etc that I should 
make sure to include in my Apache httpd 2.4 overview preso at ACNA19 next week 
(or my reverse proxy one)??

Cheers!

Re: [PATCH 63503] - Reverse proxy server - SIGSEGV

2019-08-12 Thread Jim Jagielski
Via inspection this looks quite sane.

> On Aug 12, 2019, at 3:24 PM, Eric Covener  wrote:
> 
> Hi Don, can you try this very similar patch? I applied yours to my
> sandbox to get more context and made a few minor changes (including
> pre-existing stuff that looked misleading)
> 
> http://people.apache.org/~covener/trunk-proxy-segv.diff
> 
> 



Re: [VOTE] Release httpd-2.4.41

2019-08-11 Thread Jim Jagielski
Tested:

  o macOS 10.14.6, Xcode 10.3 (64bit)
  o CentOS 5, 6 (64bit)
  o Ubuntu 14.04 LTS (64bit)

All +1: no regressions.

Thanks for RMing!

> On Aug 9, 2019, at 9:40 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ 
> 
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.41:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
> sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461 
> *httpd-2.4.41.tar.gz
> -- 
> Daniel Ruggeri



Re: [VOTE] Release httpd-2.4.40

2019-08-05 Thread Jim Jagielski
I vote -1 due to the known issue w/ building and running mod_md.

Yes, it's not a regression, but the fix is easy and version numbers are cheap. 
We should release the best possible version each time.

Let's mark 2.4.40 DOA and release 2.4.41 w/ the patch.

> On Aug 3, 2019, at 9:51 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.40:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz
> sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0
> *httpd-2.4.40.tar.gz
> 
> -- 
> Daniel Ruggeri
> 



Re: release?

2019-07-19 Thread Jim Jagielski


> On Jul 19, 2019, at 7:41 AM, Daniel Ruggeri  wrote:
> 
> Argh. I guess my mail client ate my response.
> 
> I replied yesterday with a +1 and offered to begin the process Friday (a week 
> from today).
> 
> I am available for being RM since the heavy lifting is scripted, but if you 
> would prefer to, it's all yours, Jim :-)
> 

I wouldn't mind giving it a spin... might be a good way to get a wider UX on 
the scripting.

> Happy weekend!
> -- 
> Daniel Ruggeri
> 
> On July 19, 2019 6:34:10 AM CDT, Jim Jagielski  wrote:
> +1. If Daniel doesn't have the time, I can.
> 
> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan
> 



Re: release?

2019-07-19 Thread Jim Jagielski
+1. If Daniel doesn't have the time, I can.

> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan



Re: Arranging mod_proxy_balancer to make it provider of balancer/worker.

2019-05-15 Thread Jim Jagielski
Go for it!

> On May 14, 2019, at 3:40 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I would like to be able to add worker/balancer from another module
> (mod_proxy_cluster) basically using a part of balancer_handler() to make
> a provider (like insert_update_worker(params)), any objections or
> suggestions?
> 
> -- 
> Cheers
> 
> Jean-Frederic



Re: ApacheCon call for presentations, httpd content

2019-05-09 Thread Jim Jagielski
I can always do my "httpd 2.4 overview" as well as my "httpd 2.4 reverse proxy" 
talk.

> On May 2, 2019, at 10:39 AM, Daniel Ruggeri  wrote:
> 
> Hi, Rich;
>   I was looking at the CFP and didn't quite see something that aligns with 
> httpd. These are the categories allowed:
> General
> Community
> Tomcat
> Big Data
> Machine Learning
> IoT
> Geospatial
> Cassandra
> Traffic Control Summit
> Cloudstack Collaboration Conference
> Integration
> Graph Processing
> Karaf
> Drill
> Observability
> Beam
> 
> *maybe* that has has an effect on folks' submissions? Dunno... I just 
> submitted in "general"
> -- 
> Daniel Ruggeri
> 
> On 2019/05/01 20:35:49, Rich Bowen  wrote: 
>> Hi, folks.
>> 
>> The call for presentations for ApacheCon North America closes in a
>> little less than two weeks. As of right now, as far as I can tell, there
>> is exactly zero httpd content.
>> 
>> If we want to have our project represented at ApacheCon this year, what
>> would you want to see? Is there any chance we can fill a half-day of
>> content (ie, 3-4 talks) with what new things have happened in the past
>> year, and what's important now?
>> 
>> Personally, I'd like to see a presentation on using mod_md, and perhaps
>> something on the benefits of, and use of, http2 in httpd?
>> 
>> The CFP is here - https://www.apachecon.com/acna19/cfp.html - and closes
>> May 13th.
>> 
>> Thanks!
>> 
>> --Rich
>> 



Re: [VOTE] Release httpd-2.4.39

2019-03-28 Thread Jim Jagielski
My own..

Cheers!

> On Mar 28, 2019, at 10:00 AM, Plüm, Rüdiger, Vodafone Group 
>  wrote:
> 
> What pcre lib did you use on CentOS5? The one provided by CentOS or your own?
>  
> Regards
>  
> Rüdiger
>  
>  
> C2 General
> Von: Jim Jagielski  
> Gesendet: Donnerstag, 28. März 2019 14:52
> An: httpd 
> Betreff: Re: [VOTE] Release httpd-2.4.39
>  
> Yep, CentOS5. Mostly due to the fact that regressions would likely show up 
> more readily on older OSs rather than newer ones.
>  
> Plus, there's still a crap-ton of systems using CentOS5/RHEL5
>  
> 
> On Mar 28, 2019, at 8:51 AM, Plüm, Rüdiger, Vodafone Group 
> mailto:ruediger.pl...@vodafone.com>> wrote:
>  
> 
> 
> 
> C2 General
> 
> 
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski mailto:j...@jagunet.com>>
> Gesendet: Donnerstag, 28. März 2019 13:39
> An: httpd mailto:dev@httpd.apache.org>>
> Betreff: Re: [VOTE] Release httpd-2.4.39
> 
> 
> 
> On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri  <mailto:drugg...@primary.net>>
> wrote:
> 
> 
> Hi, all;
>  Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ 
> <https://dist.apache.org/repos/dist/dev/httpd/>
> 
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.39:
> 
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256:
> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
> 2.4.39.tar.gz
> 
> 
> --
> Daniel Ruggeri
> 
> Tested and passed on the following systems (no regressions):
> 
>  o macOS 10.14.4, Xcode 10.2
>  o CentOS 5, 64bit
> 
> Really CentOS 5? Just asking because it does not receive further OS updates 
> and I wouldn't recommend to use it any longer.
> 
> Regards
> 
> Rüdiger



Re: [VOTE] Release httpd-2.4.39

2019-03-28 Thread Jim Jagielski
Yep, CentOS5. Mostly due to the fact that regressions would likely show up more 
readily on older OSs rather than newer ones.

Plus, there's still a crap-ton of systems using CentOS5/RHEL5

> On Mar 28, 2019, at 8:51 AM, Plüm, Rüdiger, Vodafone Group 
>  wrote:
> 
> 
> 
> 
> C2 General
> 
>> -Ursprüngliche Nachricht-
>> Von: Jim Jagielski 
>> Gesendet: Donnerstag, 28. März 2019 13:39
>> An: httpd 
>> Betreff: Re: [VOTE] Release httpd-2.4.39
>> 
>> 
>>> On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri 
>> wrote:
>>> 
>>> Hi, all;
>>>  Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>> 
>>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.39:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>> 
>>> The computed digests of the tarball up for vote are:
>>> sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
>>> sha256:
>> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
>> 2.4.39.tar.gz
>>> 
>>> --
>>> Daniel Ruggeri
>> 
>> Tested and passed on the following systems (no regressions):
>> 
>>  o macOS 10.14.4, Xcode 10.2
>>  o CentOS 5, 64bit
> 
> Really CentOS 5? Just asking because it does not receive further OS updates 
> and I wouldn't recommend to use it any longer.
> 
> Regards
> 
> Rüdiger



Re: [VOTE] Release httpd-2.4.39

2019-03-28 Thread Jim Jagielski


> On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.39:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256: 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 
> *httpd-2.4.39.tar.gz
> 
> -- 
> Daniel Ruggeri

Tested and passed on the following systems (no regressions):

  o macOS 10.14.4, Xcode 10.2
  o CentOS 5, 64bit
  o CentOS 6, 64bit
  o Fedora 23, 64bit

+1 for release! Thx for RMing.

Re: http://svn.apache.org/r1850745

2019-03-13 Thread Jim Jagielski


> On Mar 13, 2019, at 11:04 AM, William A Rowe Jr  wrote:
> 
> 
> As you can see, you didn't modify only modules/filters/ ... Maybe you 
> meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
>  

If that will solve the issue I'm all for it!

Thx.



Re: http://svn.apache.org/r1850745

2019-03-13 Thread Jim Jagielski



> On Mar 13, 2019, at 8:51 AM, Yann Ylavic  wrote:
> 
> On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
>> 
>> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
>>> 
>>> Is there anyone else building 2.4 on macOS under maintainer-mode
>>> who is also being affected by the above? The fact that I seem to
>>> be the anyone "complaining" :) seems weird...
>> 
>> FWIW Looks like I have maintainer mode but not libxml2
> 
> Maintainer mode and libxml2 here, but not macOS :)

Yeah, I also think it depends on the version of clang... previous versions did 
not flag

/usr/local/include/unicode/uenum.h:1:1: error: // comments are not allowed 
in this language [-Werror,-Wcomment]

as fatal errors.

Re: http://svn.apache.org/r1850745

2019-03-13 Thread Jim Jagielski
It's libxml2 from MacPorts... which is basically vanilla libxml2.

APR is 1.6.x

> On Mar 13, 2019, at 8:56 AM, Nick Kew  wrote:
> 
> 
> 
>> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
>> 
>> Is there anyone else building 2.4 on macOS under maintainer-mode
>> who is also being affected by the above? The fact that I seem to
>> be the anyone "complaining" :) seems weird...
>> 
>> Thx!
> 
> Just out of interest, is that with a libxml2-enabled APR version?
> Guess I need to test-drive that on Mac/latest, which has bitten me
> on similar platform issues before now!
> 
> -- 
> Nick Kew
> 



http://svn.apache.org/r1850745

2019-03-13 Thread Jim Jagielski
Is there anyone else building 2.4 on macOS under maintainer-mode
who is also being affected by the above? The fact that I seem to
be the anyone "complaining" :) seems weird...

Thx!


Re: lmdb, load-balancing, Sharing data about worker nodes among processes and threads in httpd

2019-02-19 Thread Jim Jagielski
One of the reasons we use mod_slotmem for load-balancing is that it
allows for other storage mechanisms to be used rather than shared memory...
mod_slotmem uses the httpd provider mechanism to extend the underlying
implementation. As such, we could use LMDB, Geode,  as our
shared storage.

> On Feb 18, 2019, at 4:56 AM, Michal Karm  wrote:
> 
> Hello,
> 
> Over the years spent on and off with mod_proxy_cluster [1]
> it has always been a problem and a bottleneck to maintain
> fresh shared information among httpd's processes and threads
> about joining _and leaving_ workers. Especially when the number
> of workers is in many hundreds and the joining/leaving fluctuation
> is a regular ongoing activity.
> 
> The implementation is basically shm/slotmem with all its
> boons and banes.
> 
> 
> QUESTIONS:
> 
> 1) Would it make sense to get rid of all shm and offload the information
> sharing for these highly dynamic load balancing scenarios to LMDB [2]?
> 
> I learned about LMDB while working with Knot Resolver [3]. Knot Resolver
> is a modern high-performance resolver (CZ-NIC uses it in our Czech TLD
> infrastructure).
> It scales with processes using event loop - and all its processes share a 
> cache of
> resolved domains [4]. Over the years LMDB emerged as the winning backend for
> that cache.
> 
> 
> 2) Given its license [5], would it ever be even possible for httpd trunk
> to depend on it?
> 
> 
> 3) Is there any similar ongoing effort? I remember Jim's notes on nng
> for messaging between workers and balancers. But I don't think he meant
> it to also serve for httpd processes to exchange information about workers...?
> Did you? :)
> 
> 
> 4) Does it even make sense to be spending any time with anything like this
> or is it a solved problem in some mod_proxy* library I am missing?
> 
> 
> Cheers
> K.
> 
> [1] http://modcluster.io/
> [2] https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database
> [3] https://github.com/CZ-NIC/knot-resolver
> [4] https://knot-resolver.readthedocs.io/en/stable/daemon.html
> [5] http://www.openldap.org/software/release/license.html
> [6] https://github.com/nanomsg/nng
> 
> Michal Karm Babacek
> 
> -- 
> Sent from my Hosaka Ono-Sendai Cyberspace 7
> 
> 



Re: http workshop

2019-01-28 Thread Jim Jagielski
i could present

> On Jan 28, 2019, at 10:21 AM, Stefan Eissing  
> wrote:
> 
> The HTTP Workshop is returning 2019 on April 2-4 in Amsterdam 
> (https://github.com/httpworkshop/workshop2019). While I attended the last 
> three shops(?), I think it would be a good opportunity for someone else from 
> the team to go there and meet some smart and friendly people from the HTTP 
> world.
> 
> The HTTP WS organisers expressed the wish to have someone from "Apache" 
> present. Anyone interested? Could also be someone from another HTTP related 
> Apache project, of course.
> 
> Cheers,
> 
> Stefan



Re: Latest test builds

2019-01-20 Thread Jim Jagielski
sorry wrong list

> On Jan 19, 2019, at 8:16 PM, Jim Jagielski  wrote:
> 
> I've uploaded the latest test builds for macOS and Linux 64.
> These are based on ~r1851640 and include 2 main updates from
> the earlier one:
> 
>  o beanshell now included
>  o macOS path bug should now be squashed 
> (https://bz.apache.org/ooo/show_bug.cgi?id=127965)
> 
> Let me know if anyone wants me to kick off a Linux 32bit
> build.
> 
> Find them here:
> 
>  http://home.apache.org/~jim/AOO-builds/4.2.0-dev-r1851640/
> 
> Cheers!



Latest test builds

2019-01-19 Thread Jim Jagielski
I've uploaded the latest test builds for macOS and Linux 64.
These are based on ~r1851640 and include 2 main updates from
the earlier one:

  o beanshell now included
  o macOS path bug should now be squashed 
(https://bz.apache.org/ooo/show_bug.cgi?id=127965)

Let me know if anyone wants me to kick off a Linux 32bit
build.

Find them here:

  http://home.apache.org/~jim/AOO-builds/4.2.0-dev-r1851640/

Cheers!

Re: [VOTE] Release httpd-2.4.38

2019-01-18 Thread Jim Jagielski
+1: Tested on:

  o macOS 10.14.2, Xcode 10.1
  o CentOS7

Will do more testing today but so far, so good.

Thx for RMing!

> On Jan 17, 2019, at 1:49 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.38:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz
> sha256: 38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6 
> *httpd-2.4.38.tar.gz
> 
> -- 
> Daniel Ruggeri



Re: [VOTE] Release httpd-2.4.28

2019-01-17 Thread Jim Jagielski
Ahhh good.

> On Jan 17, 2019, at 12:46 PM, Yann Ylavic  wrote:
> 
> On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski  wrote:
>> 
>> Note that simply changing the commit msg logs does not solve the problem. 
>> There is,
>> in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 
>> 2.4.28 tag... :(
> 
> Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed 
> already.



Re: [VOTE] Release httpd-2.4.28

2019-01-17 Thread Jim Jagielski
Note that simply changing the commit msg logs does not solve the problem. There 
is,
in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 2.4.28 
tag... :(

Re: [VOTE] Release httpd-2.4.28

2019-01-17 Thread Jim Jagielski
Shouldn't this be 2.4.38??

> On Jan 17, 2019, at 12:13 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
>   Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.28:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz
> sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 
> *httpd-2.4.28.tar.gz
> 
> -- 
> Daniel Ruggeri



Re: svn commit: r1851549 - /httpd/httpd/tags/2.4.28/2.4.x/

2019-01-17 Thread Jim Jagielski
2.4.28?

> On Jan 17, 2019, at 12:08 PM, drugg...@apache.org wrote:
> 
> Author: druggeri
> Date: Thu Jan 17 17:08:22 2019
> New Revision: 1851549
> 
> URL: http://svn.apache.org/viewvc?rev=1851549=rev
> Log:
> Tag HEAD of 2.4.x as 2.4.28
> 
> Added:
>httpd/httpd/tags/2.4.28/2.4.x/   (props changed)
>  - copied from r1851548, httpd/httpd/branches/2.4.x/
> 
> Propchange: httpd/httpd/tags/2.4.28/2.4.x/
> --
> --- svn:ignore (added)
> +++ svn:ignore Thu Jan 17 17:08:22 2019
> @@ -0,0 +1,45 @@
> +config.nice
> +configure
> +missing
> +install-sh
> +mkinstalldirs
> +aclocal.m4
> +.deps
> +generated_lists
> +buildmk.stamp
> +config.log
> +Makefile
> +libtool
> +shlibtool
> +config.status
> +modules.c
> +config.cache
> +.libs
> +httpd
> +httpd.exe
> +modules.lo
> +Debug
> +Release
> +LibD
> +LibR
> +Apache.suo
> +Apache.ncb
> +Apache.opt
> +apachecore.dll
> +*.x
> +*.aps
> +*.plg
> +*.dep
> +*.mak
> +*.rc
> +Apache.sln
> +BuildLog.htm
> +*.stc
> +*.stt
> +*.sto
> +*.vcproj
> +*.vcproj.*
> +autom4te.cache
> +httpd.spec
> +tags
> +TAGS
> 
> Propchange: httpd/httpd/tags/2.4.28/2.4.x/
> --
> --- svn:mergeinfo (added)
> +++ svn:mergeinfo Thu Jan 17 17:08:22 2019
> @@ -0,0 +1,11 @@
> +/httpd/httpd/branches/2.4.17-protocols-changes:1712542-1715252
> +/httpd/httpd/branches/2.4.17-protocols-http2:1701609-1705681
> +/httpd/httpd/branches/2.4.x-mod_md:1816423-1821089
> +/httpd/httpd/branches/2.4.x-mpm_fdqueue:1824383-1824864
> +/httpd/httpd/branches/revert-ap-ldap:1150158-1150173
> +/httpd/httpd/branches/tlsv1.3-for-2.4.x:1840105-1841571
> +/httpd/httpd/branches/trunk-buildconf-noapr:1780253-1795930
> +/httpd/httpd/branches/trunk-md:1804087-1804529
> +/httpd/httpd/branches/trunk-override-index:1793921-1793931
> +/httpd/httpd/branches/wombat-integration:723609-723841
> +/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12
> 15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167
> ,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341905-1341906,1341913,1341930,1342065,1343085,1343087,1343094,1343099,1343109,1343935,1344712,1345147,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,1363035,1363183,1363186,1363312,1363440,1363557,1363589,1363829,1363832,1363836-1363837,1363853,1364133,1364138,1364229,1364601,1364695,1365001,1365020,1365029,1365479,1366319,1366344,1366621,1367778,1367819,1368053,1368058,1368094,1368121,1368131,1368393,1368396,1369419,1369568,1369
> 

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

2019-01-16 Thread Jim Jagielski
I specifically didn't use  #pragma GCC diagnostic push
in order to avoid this exact kind of discussion...

> On Jan 16, 2019, at 4:46 PM, Jim Jagielski  wrote:
> 
> I'm sorry but I'm confused. The patch is as specific as you can get. It just 
> adds the minimal option and JUST for filters and JUST if libxml2 is part of 
> the build. Anything else seems more disruptive than that. So why are the more 
> disruptive changes preferred? I'm just trying to understand the logic there.
> 
>> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr  wrote:
>> 
>> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
>> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
>> in maintainer mode, or simply switch to -std=c99 presuming that more 
>> and more of the system headers follow c99 syntax over time. 
>> And revert the tweak of modules/filters/config.m4.
>> 
>> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
>>  wrote:
>> 
>> C2 General
>> 
>> > -Ursprüngliche Nachricht-
>> > Von: Stefan Eissing 
>> > Gesendet: Mittwoch, 16. Januar 2019 10:00
>> > An: dev@httpd.apache.org
>> > Betreff: Re: svn commit: r1850745 -
>> > /httpd/httpd/trunk/modules/filters/config.m4
>> > 
>> > 
>> > 
>> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr > > clan.net>:
>> > >
>> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  wrote:
>> > >
>> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
>> > > >
>> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski 
>> > wrote:
>> > > >>
>> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr 
>> > wrote:
>> > > >>
>> > > >> Hi Jim,
>> > > >>
>> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
>> > building on the Fedora 29, largely frozen end-of-july. Reverting the
>> > patch below and toggling -std=c89 to -std=c99 in configure.in building
>> > all but two modules from trunk is building clean, and results in this
>> > command for error checking;
>> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
>> > pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
>> > -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
>> > Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -
>> > D_GNU_SOURCE -DAP_DEBUG
>> > > >>
>> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
>> > not suggesting we change the general builds from c89 in the 2.4 branch,
>> > but that is something we might want to consider for trunk, 20 years out.
>> > > >>
>> > > >>
>> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
>> > considering that we are in 2019 already :)
>> > > >>
>> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
>> > anyway.
>> > > >
>> > > > As a binary distributor, even though a C99 compiler may be available
>> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
>> > > > 2.4.
>> > >
>> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
>> > :)
>> > >
>> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
>> > c89) possibly more difficult. This is either a good thing or a bad
>> > thing. So far, however, iirc we have not had any issues sticking with
>> > c89 and I don't think the above would warrant such a change. IMO of
>> > course.
>> > >
>> > > I might not have been clear, above. I'm not suggesting changing things
>> > for the
>> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
>> > think we should
>> > > have this discussion of when we will begin accepting c99 source
>> > patches, but
>> > > that isn't the immediate problem you've tripped over.
>> > >
>> > > I see several options;
>> > >
>> > >   Only for maintainer mode, where we are strictly handling all errors,
>> > always
>> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
>> > may arise.)
>> > >   All the system headers using c99 (or earlier) semantics should
>>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

2019-01-16 Thread Jim Jagielski
I'm sorry but I'm confused. The patch is as specific as you can get. It just 
adds the minimal option and JUST for filters and JUST if libxml2 is part of the 
build. Anything else seems more disruptive than that. So why are the more 
disruptive changes preferred? I'm just trying to understand the logic there.

> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr  wrote:
> 
> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
> in maintainer mode, or simply switch to -std=c99 presuming that more 
> and more of the system headers follow c99 syntax over time. 
> And revert the tweak of modules/filters/config.m4.
> 
> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
> mailto:ruediger.pl...@vodafone.com>> wrote:
> 
> C2 General
> 
> > -Ursprüngliche Nachricht-
> > Von: Stefan Eissing  > <mailto:stefan.eiss...@greenbytes.de>>
> > Gesendet: Mittwoch, 16. Januar 2019 10:00
> > An: dev@httpd.apache.org <mailto:dev@httpd.apache.org>
> > Betreff: Re: svn commit: r1850745 -
> > /httpd/httpd/trunk/modules/filters/config.m4
> > 
> > 
> > 
> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr  > clan.net <http://clan.net/>>:
> > >
> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  > > <mailto:j...@jagunet.com>> wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener  > > > <mailto:cove...@gmail.com>> wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski  > > > <mailto:j...@jagunet.com>>
> > wrote:
> > > >>
> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  > > >> <mailto:wr...@rowe-clan.net>>
> > wrote:
> > > >>
> > > >> Hi Jim,
> > > >>
> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> > building on the Fedora 29, largely frozen end-of-july. Reverting the
> > patch below and toggling -std=c89 to -std=c99 in configure.in 
> > <http://configure.in/> building
> > all but two modules from trunk is building clean, and results in this
> > command for error checking;
> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
> > pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
> > Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -
> > D_GNU_SOURCE -DAP_DEBUG
> > > >>
> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
> > not suggesting we change the general builds from c89 in the 2.4 branch,
> > but that is something we might want to consider for trunk, 20 years out.
> > > >>
> > > >>
> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
> > considering that we are in 2019 already :)
> > > >>
> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
> > anyway.
> > > >
> > > > As a binary distributor, even though a C99 compiler may be available
> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
> > > > 2.4.
> > >
> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
> > :)
> > >
> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
> > c89) possibly more difficult. This is either a good thing or a bad
> > thing. So far, however, iirc we have not had any issues sticking with
> > c89 and I don't think the above would warrant such a change. IMO of
> > course.
> > >
> > > I might not have been clear, above. I'm not suggesting changing things
> > for the
> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
> > think we should
> > > have this discussion of when we will begin accepting c99 source
> > patches, but
> > > that isn't the immediate problem you've tripped over.
> > >
> > > I see several options;
> > >
> > >   Only for maintainer mode, where we are strictly handling all errors,
> > always
> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
> > may arise.)
> > >   All the system headers using c99 (or earlier) semantics should
> > behave well.
> > >
> > >   Or, for maintainer mode, always relax the comments restriction only
> > so we
>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

2019-01-15 Thread Jim Jagielski



> On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
> 
> On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski  wrote:
>> 
>> 
>> 
>> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  wrote:
>> 
>> Hi Jim,
>> 
>> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm building 
>> on the Fedora 29, largely frozen end-of-july. Reverting the patch below and 
>> toggling -std=c89 to -std=c99 in configure.in building all but two modules 
>> from trunk is building clean, and results in this command for error checking;
>> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread 
>> -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes 
>> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith 
>> -Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE 
>> -DAP_DEBUG
>> 
>> Is it reasonable to enforce c99 limitations at this late date? I'm not 
>> suggesting we change the general builds from c89 in the 2.4 branch, but that 
>> is something we might want to consider for trunk, 20 years out.
>> 
>> 
>> Personally, I'd be fine allowing c99 in both 2.4 and trunk, considering that 
>> we are in 2019 already :)
>> 
>> Any platform that lacks a c99 compatible CC likely doesn't build anyway.
> 
> As a binary distributor, even though a C99 compiler may be available
> on platform X, it might not be in use.  Wouldn't love seeing it in
> 2.4.

I'm not proposing a change for 2.4... but I wouldn't oppose it either :)

Allowing c99 for trunk would make backporting to 2.4 (which would stay c89) 
possibly more difficult. This is either a good thing or a bad thing. So far, 
however, iirc we have not had any issues sticking with c89 and I don't think 
the above would warrant such a change. IMO of course.

Re: [NOTICE] Intent to T 2.4.28

2019-01-15 Thread Jim Jagielski
Could I please get one more vote on adding in mod_socache_redis from trunk...

It's been waiting for several releases by now.

> On Jan 15, 2019, at 7:27 AM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> It's been a while since we've rolled a release and we've had some recent 
> movement, so I'd like to propose T of 2.4.38 in the next day or two. I'll 
> plan to proceed Thursday morning (US Central).
> -- 
> Daniel Ruggeri



Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

2019-01-15 Thread Jim Jagielski


> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr  wrote:
> 
> Hi Jim,
> 
> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm building on 
> the Fedora 29, largely frozen end-of-july. Reverting the patch below and 
> toggling -std=c89 to -std=c99 in configure.in  building 
> all but two modules from trunk is building clean, and results in this command 
> for error checking;
> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread -std=c99 
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations 
> -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security 
> -Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE -DAP_DEBUG
> 
> Is it reasonable to enforce c99 limitations at this late date? I'm not 
> suggesting we change the general builds from c89 in the 2.4 branch, but that 
> is something we might want to consider for trunk, 20 years out.

Personally, I'd be fine allowing c99 in both 2.4 and trunk, considering that we 
are in 2019 already :)

Any platform that lacks a c99 compatible CC likely doesn't build anyway.

Re: [PATCH] fix test/mod_dialup.c for non-threaded APR

2019-01-08 Thread Jim Jagielski
+1 by me.

> On Jan 8, 2019, at 7:09 AM, Stefan Sperling  wrote:
> 
> See https://svn.apache.org/r1663375 for a related fix by covener.
> Which, by the way, should probably be backported to 2.4; I see a failure
> on a buildbot which deliberately builds with non-threaded APR to ensure
> that this configuration remains in SVN's test matrix:
> https://ci.apache.org/builders/svn-bb-openbsd/builds/272/steps/Build/logs/stdio
> 
> This patch hasn't even been compile tested but looks obvious enough.
> Fine to commit?
> 
> Index: modules/test/mod_dialup.c
> ===
> --- modules/test/mod_dialup.c (revision 1850735)
> +++ modules/test/mod_dialup.c (working copy)
> @@ -107,7 +107,9 @@ dialup_callback(void *baton)
> dialup_baton_t *db = (dialup_baton_t *)baton;
> conn_rec *c = db->r->connection;
> 
> +#if APR_HAS_THREADS
> apr_thread_mutex_lock(db->r->invoke_mtx);
> +#endif
> 
> status = dialup_send_pulse(db);
> 
> @@ -115,7 +117,9 @@ dialup_callback(void *baton)
> ap_mpm_register_timed_callback(apr_time_from_sec(1), dialup_callback, 
> baton);
> }
> else if (status == DONE) {
> +#if APR_HAS_THREADS
> apr_thread_mutex_unlock(db->r->invoke_mtx);
> +#endif
> ap_finalize_request_protocol(db->r);
> ap_process_request_after_handler(db->r);
> return;
> @@ -127,7 +131,9 @@ dialup_callback(void *baton)
> ap_die(status, db->r);
> }
> 
> +#if APR_HAS_THREADS
> apr_thread_mutex_unlock(db->r->invoke_mtx);
> +#endif
> 
> ap_mpm_resume_suspended(c);
> }



Jim's been busy

2018-12-11 Thread Jim Jagielski
I've been slammed both at work and personal and haven't had
time to do much httpd stuff... just a FYI in case people were
curious. Should free up by the end of the month.


Re: Plan to add sandbox branch

2018-11-30 Thread Jim Jagielski
Hmmm... this has me thinking about maybe using the provider interface to 
implement the communication mechanism... let me mull this over.

> On Nov 30, 2018, at 8:27 AM, Jim Jagielski  wrote:
> 
> Yeah, I looked for something else, esp various pubsub implementations, but 
> they really didn't fit in with what was needed.
> 
> 
>> On Nov 29, 2018, at 3:02 AM, jean-frederic clere  wrote:
>> 
>> On 29/11/2018 07:02, Christophe JAILLET wrote:
>>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>>> Hi, Jim;
>>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>>> protocol. Any pointers you can share?
>>>> 
>>> Hi
>>> 
>>> Not sure if the answers already posted are what you are looking for.
>>> Here are some links:
>>>   https://nanomsg.org/gettingstarted/survey.html and other resources on
>>> https://nanomsg.org/
>>> 
>>> 
>>> CJ
>>> 
>> 
>> So as I am looking to proxy tomcat using httpd I need a 'pure" java
>> implementation for tomcat, it seems that it is missing for the moment,
>> correct?
>> 
>> -- 
>> Cheers
>> 
>> Jean-Frederic
> 



Re: Plan to add sandbox branch

2018-11-30 Thread Jim Jagielski
Yeah, I looked for something else, esp various pubsub implementations, but they 
really didn't fit in with what was needed.


> On Nov 29, 2018, at 3:02 AM, jean-frederic clere  wrote:
> 
> On 29/11/2018 07:02, Christophe JAILLET wrote:
>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :
>>> Hi, Jim;
>>> I'm coming up empty on a search against the Google-machine for SURVEY
>>> protocol. Any pointers you can share?
>>> 
>> Hi
>> 
>> Not sure if the answers already posted are what you are looking for.
>> Here are some links:
>>https://nanomsg.org/gettingstarted/survey.html and other resources on
>> https://nanomsg.org/
>> 
>> 
>> CJ
>> 
> 
> So as I am looking to proxy tomcat using httpd I need a 'pure" java
> implementation for tomcat, it seems that it is missing for the moment,
> correct?
> 
> -- 
> Cheers
> 
> Jean-Frederic



Re: Plan to add sandbox branch

2018-11-28 Thread Jim Jagielski
https://nanomsg.org

> On Nov 27, 2018, at 8:33 PM, Daniel Ruggeri  wrote:
> 
> Hi, Jim;
> I'm coming up empty on a search against the Google-machine for SURVEY 
> protocol. Any pointers you can share?
> 
> I'm also curious what your thoughts are about dealing with growth of the 
> worker pool beyond the control of the proxy admin. For example, if I 
> configure a balancer for 10 nodes, I have an idea of tuning parameters I 
> might set differently than if the number of backends is in the tens of 
> servers.

Since nanomsg/nng will provide the communication between httpd and the 
backends, we could add something like a CONFIG survey that allows for the 
backends to "suggest" params.

> -- 
> Daniel Ruggeri
> 
> On November 27, 2018 5:23:25 AM CST, Jim Jagielski  wrote:
> In the coming week or so, I will be committing my load balance,
> load determination and discovery work to a sandbox trunk. Many
> people have asked for more info, so here we go.
> 
> Basically, this new feature uses nanomsg (nng) to implement the
> SURVEY protocol between workers (nodes) and the front end server.
> The proxy server will send out MEMBERSHIP and STATUS surveys, that
> nodes can respond to; thus new nodes can automagically add themselves
> as they come up as well as remove themselves when they restart or
> shutdown via MEMBERSHIP. STATUS can be used to provide real-time
> load on each node, which will be sent via a __packed__ struct,
> ala NTP and other common usage patterns, in which 32bit fields are
> converted from endian-ness to network and back. That STATUS info can
> be used for "intelligent" load balancing and will provide some
> typical server metrics such as memory, # of cpus, etc...



Plan to add sandbox branch

2018-11-27 Thread Jim Jagielski
In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...


Re: 2.4.38

2018-11-09 Thread Jim Jagielski



> On Nov 9, 2018, at 2:54 PM, Graham Leggett  wrote:
> 
> On 09 Nov 2018, at 17:51, Stefan Eissing  wrote:
> 
>> So, the chance is high that releases we do will work for most of you.
>> AND the chance is high that releases might break something for some of you 
>> (hopefully a few).
> 
> The chance is very low that releases might break something, and this is done 
> by design.
> 
> The place where we might break something is trunk. Before you get anywhere 
> near a release, you have to carve out your change, and propose it for 
> backport to a release branch. This is the first check. Two other people will 
> then check your backport, and if problems are found you’ll be asked to fix 
> it. That’s the second and third check. Then a release is proposed. A tarball 
> is cut, and a whole lot of new people do checks on the tarball. In the case 
> of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, ninth, tenth 
> and eleventh check for the 8 people who tested it.
> 
> This strategy has worked very well for us since the 1990s, and we must not 
> understate its importance.
> 

If it ain't broke. :)



Re: Load balancing and load determination

2018-11-08 Thread Jim Jagielski
I have a semi-working implementation that I'll be committing to trunk in a 
bit...

> On Nov 8, 2018, at 1:33 AM, Mladen Turk  wrote:
> 
> On 30.10.2018. 13:53, Jim Jagielski wrote:
>> As some of you know, one of my passions and area of focus is
>> on the use of Apache httpd as a reverse proxy and, as such, load
>> balancing, failover, etc are of vital interest to me.
> 
> Been a while, but seems I'm back :D
> Love the idea to have more intelligent then "lets guess"
> way of deducting the load balancer score.
> 
> What we did for heartbeat/heartmonitor/watchdog can be used
> for collecting backend data.
> 
> The thing I'm trying to do is the way that backend can
> register or remove itself as node inside load balancer.
> That would also require some sort of backend-server communication,
> shared memory management (mod_slotmem maybe), and a way to
> survive graceful restart.
> 
> Backend sending its load status at regular intervals would
> be addition to "I'm here, count me in" or
> "I'm out, bye, good luck with other nodes".
> 
> What do you think?
> 
> 
> 
> Regards
> -- 
> ^TM



2.4.38

2018-11-07 Thread Jim Jagielski
Now that we have a 2.4.37 out, one in which the number of enhancements and 
fixes and feature were limited, it makes sense to consider having a 2.4.38 
release somewhat "soonish", esp considering the number of backports that lack 
only a single vote.

Comments?

Re: Load balancing and load determination

2018-11-06 Thread Jim Jagielski
Which is why we allow for both pre-send checks and out-of-band health checks...

> On Nov 5, 2018, at 10:58 AM, William A Rowe Jr  wrote:
> 
> 
> The last thing we want are the routing headaches of contacting an
> ever-changing list one-or-many potential balancers. And we can't
> rely on a dying lbmember to "check in" that it isn't functional. Since
> the balancer must already start requests to the backend, having that
> backend supplement the responses with its health status is simple.



Re: Load balancing and load determination

2018-11-05 Thread Jim Jagielski
I was thinking about something more robust and usable than heartbeat (due to 
multicast) but similar in basic concept.

> On Nov 5, 2018, at 8:48 AM, jean-frederic clere  wrote:
> 
> On 30/10/2018 13:53, Jim Jagielski wrote:
>> As some of you know, one of my passions and area of focus is
>> on the use of Apache httpd as a reverse proxy and, as such, load
>> balancing, failover, etc are of vital interest to me.
>> 
>> One topic which I have mulling over, off and on, has been the
>> idea of some sort of universal load number, that could be used
>> and agreed upon by web servers. Right now, the reverse proxy
>> "guesses" the load on the backend servers which is OK, and
>> works well enough, but it would be great if it actually "knew"
>> the current loads on those servers. I already have code that
>> shares basic architectural info, such as number of CPUs, available
>> memory, loadavg, etc which can help, of course, but again, all
>> this info can be used to *infer* the current status of those backend
>> servers; it doesn't really provide what the current load actually
>> *is*.
>> 
>> So I was thinking maybe some sort of small, simple and "fast"
>> benchmark which could be run by the backends as part of their
>> "status" update to the front-end reverse proxy server... something
>> that shows general capability at that point in time, like Hanoi or
>> something similar. Or maybe some hash function. Some simple code
>> that could be used to create that "universal" load number.
>> 
>> Thoughts? Ideas? Comments? Suggestions? :)
> 
> having the back-ends to provide the load they are able to handle
> lbfactor (via w_lf or somethere similar. That requires the back-ends to
> be able to send request to httpd balancer-manager handler.
> 
>> 
> 
> 
> -- 
> Cheers
> 
> Jean-Frederic



Re: __attribute__

2018-11-02 Thread Jim Jagielski


> On Nov 1, 2018, at 5:53 PM, William A Rowe Jr  wrote:
> 
> On Thu, Nov 1, 2018 at 3:31 PM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
> Since __attribute__ is used in various places in trunk and 2.4, is it safe to 
> assume that I can write something that requires __attribute__(packed)?
> 
> No ... but surely you meant to write __attribute__((packed))

Why No? And don't call me Shirley.

> 
> The real question is... why?

Why does anyone use it because they need a packed struct.

> It is sorely suboptimal except on x86_64 where the cpu handles the heavy lift 
> ... the compiler must cope with it on MIPS/SPARC/POWER etc, may break atomic 
> updates (our atomics don't protect against this), and doesn't address 
> endianness. It all leads to lots of other questions...
> 
> https://stackoverflow.com/questions/45116212/are-packed-structs-portable 
> <https://stackoverflow.com/questions/45116212/are-packed-structs-portable> 
> https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe
>  
> <https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe>

All known and considered, but thanks for the intro to C lesson.

> 
> Adding this to any existing public struct definition is not backportable to 
> 2.4.x.

Of course. Who would propose such a thing??

> 
> A use case would be helpful provide a fair answer to your question.


I plan to use it in a very NTP-like way.

__attribute__

2018-11-01 Thread Jim Jagielski
Since __attribute__ is used in various places in trunk and 2.4, is it safe to 
assume that I can write something that requires __attribute__(packed)?

Re: Load balancing and load determination

2018-10-30 Thread Jim Jagielski



> On Oct 30, 2018, at 9:06 AM, Daniel Ruggeri  wrote:
> 
> Hi, Jim J;
> I recall a while back that Jim Riggs proposed a spec for exactly this a while 
> back... I think it was shared here on list and some light iteration was done. 
> IIUC, he was even planning to present it at ACNA until travel plans fell 
> through.
> 


https://lists.apache.org/thread.html/ca115bd3f21f7da91fa01a4d83af7d73987750e1e48bb2bf76236e52@1430369651@%3Cdev.httpd.apache.org%3E





Re: Load balancing and load determination

2018-10-30 Thread Jim Jagielski
The only reason why I brought up the concept of a benchmark is because it is 
dead easy to provide the source for said benchmark and have backend servers 
simply time how long it takes to run it each status update. Each backend would 
simply then send the "time taken" and that would provide some measure of how 
beefy and/or loaded said server was.

The main consideration is one of consistency... unless there is some agreed 
upon "standard" then comparisons are worthless and the resulting load balancing 
will be inaccurate. For example, say that Apache is front-ending 10 servers, 5 
are Apache and other 5 are Foo, but Foo consistently falsifies it's capability 
simply to ensure that it gets all the traffic. Sure, you can adjust settings on 
the front end to offset that, but that defeats the whole purpose of some 
*accurate*, objective measure of capability.

Yeah, I recall JR posting something after I brought up this topic at one of my 
ApacheCon sessions...

Maybe it's more of an "availability factor" than a load factor... with 0 being 
"send me nothing" and 1 being "I am completely unloaded" and decimal values 
between indicating their "availability" to handle traffic.

> On Oct 30, 2018, at 9:06 AM, Daniel Ruggeri  wrote:
> 
> Hi, Jim J;
> I recall a while back that Jim Riggs proposed a spec for exactly this a while 
> back... I think it was shared here on list and some light iteration was done. 
> IIUC, he was even planning to present it at ACNA until travel plans fell 
> through.
> 
> Hi, Jim R;
> Any chance you have the latest and greatest, or is the version from the list 
> archives current state?
> 
> 
> One of the things I recall *really liking* from the recommendation is letting 
> the backend decide its factor based on whatever it believes is most 
> important. In some servers, that may be available threads. In others it could 
> be percentage of memory used. Still yet, other servers may decide based on 
> number of idle GPUs on-system. I think this is roughly the same you are 
> suggesting, Jim J, but I struggle to think of a universal benchmark because 
> backends are so varied.
> -- 
> Daniel Ruggeri
> 
> On October 30, 2018 7:53:20 AM CDT, Jim Jagielski  wrote:
> As some of you know, one of my passions and area of focus is
> on the use of Apache httpd as a reverse proxy and, as such, load
> balancing, failover, etc are of vital interest to me.
> 
> One topic which I have mulling over, off and on, has been the
> idea of some sort of universal load number, that could be used
> and agreed upon by web servers. Right now, the reverse proxy
> "guesses" the load on the backend servers which is OK, and
> works well enough, but it would be great if it actually "knew"
> the current loads on those servers. I already have code that
> shares basic architectural info, such as number of CPUs, available
> memory, loadavg, etc which can help, of course, but again, all
> this info can be used to *infer* the current status of those backend
> servers; it doesn't really provide what the current load actually
> *is*.
> 
> So I was thinking maybe some sort of small, simple and "fast"
> benchmark which could be run by the backends as part of their
> "status" update to the front-end reverse proxy server... something
> that shows general capability at that point in time, like Hanoi or
> something similar. Or maybe some hash function. Some simple code
> that could be used to create that "universal" load number.
> 
> Thoughts? Ideas? Comments? Suggestions? :)



Load balancing and load determination

2018-10-30 Thread Jim Jagielski
As some of you know, one of my passions and area of focus is
on the use of Apache httpd as a reverse proxy and, as such, load
balancing, failover, etc are of vital interest to me.

One topic which I have mulling over, off and on, has been the
idea of some sort of universal load number, that could be used
and agreed upon by web servers. Right now, the reverse proxy
"guesses" the load on the backend servers which is OK, and
works well enough, but it would be great if it actually "knew"
the current loads on those servers. I already have code that
shares basic architectural info, such as number of CPUs, available
memory, loadavg, etc which can help, of course, but again, all
this info can be used to *infer* the current status of those backend
servers; it doesn't really provide what the current load actually
*is*.

So I was thinking maybe some sort of small, simple and "fast"
benchmark which could be run by the backends as part of their
"status" update to the front-end reverse proxy server... something
that shows general capability at that point in time, like Hanoi or
something similar. Or maybe some hash function. Some simple code
that could be used to create that "universal" load number.

Thoughts? Ideas? Comments? Suggestions? :)


Re: SetHandler balancer-manager question.

2018-10-23 Thread Jim Jagielski
Yes, it is normal and expected behavior, but one can say that such behavior 
isn't "correct" or "should be changed", esp now that we can add members 
dynamically. So I would be +1 on changing the code to show all balancers, 
regardless of whether they have workers/members or not.

> On Oct 23, 2018, at 5:25 AM, jean-frederic clere  wrote:
> 
> Hi,
> 
> I have started to look how to enhance mod_proxy_balancer to replace
> mod_cluster, the first question is it normal that a balancer without
> workers is NOT displayed by the handler?
> -- 
> Cheers
> 
> Jean-Frederic



Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
Well, we'll see if other macOS users also have the same failures... that will 
determine if my hypothesis is correct.

> On Oct 22, 2018, at 11:37 AM, Stefan Eissing  
> wrote:
> 
> dAMn! uSABilitY StRiks aGAIn!
> 
>> Am 22.10.2018 um 17:34 schrieb Jim Jagielski :
>> 
>> OK, I think I know what may be happening; I am guessing its due to the macOS 
>> file system being case insensitive but case preserving...
> 



Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
OK, I think I know what may be happening; I am guessing its due to the macOS 
file system being case insensitive but case preserving...

Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Jim Jagielski
The latest update to usertrack works. Thx! speling still bad:

On httpd-2.4 HEAD:

  t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
  # Failed test 12 in t/modules/speling.t at line 50 fail #5
  # Failed test 35 in t/modules/speling.t at line 46 fail #18
  # Failed test 36 in t/modules/speling.t at line 50 fail #9
  t/modules/speling.t . Failed 4/48 subtests
(less 13 skipped subtests: 31 okay)

On trunk:

  t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
  # Failed test 12 in t/modules/speling.t at line 50 fail #5
  # Failed test 13 in t/modules/speling.t at line 46 fail #7
  # Failed test 14 in t/modules/speling.t at line 50 fail #6
  # Failed test 15 in t/modules/speling.t at line 46 fail #8
  # Failed test 16 in t/modules/speling.t at line 50 fail #7
  # Failed test 35 in t/modules/speling.t at line 46 fail #18
  # Failed test 36 in t/modules/speling.t at line 50 fail #9
  # Failed test 37 in t/modules/speling.t at line 46 fail #19
  # Failed test 38 in t/modules/speling.t at line 50 fail #10
  # Failed test 39 in t/modules/speling.t at line 46 fail #20
  # Failed test 40 in t/modules/speling.t at line 50 fail #11
  t/modules/speling.t . Failed 12/48 subtests
  (less 13 skipped subtests: 23 okay)

This is on macOS. The speling tests show:

# testing : Checking case. Expecting: 301
# expected: 301
# received: '200'
not ok 11
# testing : Redirect ok
# expected: qr/good\.html|several1\.html/
# received: '
# 
# 404 Not Found
# 
# Not Found
# The requested URL /modules/speling/nocase/good.wrong_ext was not found on 
this server.
# 
# '
not ok 14
# Failed test 13 in t/modules/speling.t at line 46 fail #7
# Failed test 14 in t/modules/speling.t at line 50 fail #6
# testing : Checking NC wrong extension. Expecting: 300
# expected: 300
# received: '404'
not ok 15
# testing : Redirect ok
# expected: qr/good\.html|several1\.html/
# received: '
# 
# 404 Not Found
# 
# Not Found
# The requested URL /modules/speling/nocase/GOOD.wrong_ext was not found on 
this server.
# 
# '

  1   2   3   4   5   6   7   8   9   10   >