Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

Questions on open ports between trunk and 2.4.x

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


rainer.jung at kippdata

Jan 31, 2012, 7:07 AM

Post #1 of 17 (1136 views)
Permalink
Questions on open ports between trunk and 2.4.x

I backported some trunk changes to 2.4.x (mostly cosmetic ones) and a
few changes also in the other direction to keep code changes small in
parts were there are still no functional changes.

A few backports are open, because I'm not sure, whether we want to
backport. I left out the obvious changes (serf, apreq and similar), and
also the changes related to the recent core filter improvements, but the
below ones are not obvious to me. Comments on them welcome:

1) mod_reqtimeout
=================

r1202255 | pquerna | 2011-11-15 16:49:19 +0100 (Tue, 15 Nov 2011) | 1 line
disable mod_reqtimeout if not configured

It looks like mod_reqtimeout is now inactive by default in trunk, but
ses some builtin default values in 2.4.x. Is that what we want? I'd
expected that if we have it automatically use default values when loaded
in 2.4.x, we would want the same behaviour in trunk.


2) log tags
===========

r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 lines
Add APLOGNO() macro for unique tags for every log message.
Add some scripts to make adding these tags easier.

This has only been backported partially. The directory
docs/log-message-tags is mising in 2.4.x as well as the update-log-tags
and update-log-msg-tags targets in Makefile.


3) Recent install optimization
==============================

r1237447 | sf | 2012-01-29 21:11:55 +0100 (Sun, 29 Jan 2012) | 11 lines

Install multiple files per install.sh invocation

Libtool and BSD install support installing several files in one run.
Add support to install.sh and instdso.sh, too.
Replace for-loops in the Makefiles.

This reduces 'make install' time by approx. 50% because we save
lots of calls to the huge libtool shell script.

The AIX-specific magic in instdso.sh could use some testing.


Backport?


4) mod_proxy_html
=================

r1200556 | jorton | 2011-11-10 22:21:03 +0100 (Thu, 10 Nov 2011) | 3 lines

* modules/filters/mod_proxy_html.c: Fix various code style issues. Use
apr_is* ctype macro wrappers.


I guess we want that also in 2.4.x.


5) mod_authnz_ldap
==================

r1231257 | covener | 2012-01-13 20:18:03 +0100 (Fri, 13 Jan 2012) | 3 lines

whitespace only: shift a block refactored in r1231255 over 8 spaces.


r1231255 | covener | 2012-01-13 20:16:50 +0100 (Fri, 13 Jan 2012) | 5 lines

*) mod_authnz_ldap: Don't try a potentially expensive nested groups
search before exhausting all AuthLDAPGroupAttribute checks on the
current group. PR52464


6) mod_cache
============

Applied to 2.4.x but not in trunk:

r1208384 | minfrin | 2011-11-30 12:21:43 +0100 (Wed, 30 Nov 2011) | 4 lines

mod_cache: Revert
http://svn.apache.org/viewvc?view=revision&revision=1070179
as per the following thread:
http://www.gossamer-threads.com/lists/apache/dev/395830?do=post_view_threaded#395830

------------------------------------------------------------------------
r1208824 | minfrin | 2011-11-30 23:00:43 +0100 (Wed, 30 Nov 2011) | 4 lines

Backport:
mod_cache: Apply the API change that allows future mod_cache providers to
invalidate cache entries, which will fix PR15868.


Should both be ported forwards?


7) .htaccess handling
=====================

------------------------------------------------------------------------
r1229021 | niq | 2012-01-09 05:01:06 +0100 (Mon, 09 Jan 2012) | 5 lines

Core configuration: add AllowOverride option to treat syntax
errors in .htaccess as non-fatal.
PR 52439


8) ErrorLog directory checking
==============================

r1225199 | sf | 2011-12-28 15:54:49 +0100 (Wed, 28 Dec 2011) | 6 lines

Check during configtest that the directories for error logs exist

Testing under Windows is welcome

PR: 29941


9) Event MPM
============

I think everything apart from Paul's new queue has been backported, but
please double check this list:

------------------------------------------------------------------------
r1203858 | trawick | 2011-11-18 22:39:33 +0100 (Fri, 18 Nov 2011) | 4 lines

follow up to r1202257 -- perform normal wakeup processing when
APR_EINTR is seen from apr_pollset_poll(), with expectation that
it was triggered by apr_pollset_wakeup()

------------------------------------------------------------------------
r1203404 | trawick | 2011-11-17 23:48:35 +0100 (Thu, 17 Nov 2011) | 10 lines

event no longer requires APR_POLLSET_THREADSAFE, or any
other non-standard feature (all but OS/2 have APR_POLLSET_WAKEABLE)

config-foo: don't require thread-safe pollset in order to
build event

event.c: don't stress APR_ENOTIMPL in apr_pollset_create errors;
just give the standard "check system or user limits"
message

------------------------------------------------------------------------
r1202395 | trawick | 2011-11-15 20:38:31 +0100 (Tue, 15 Nov 2011) | 2 lines

spellcheck r1202258

------------------------------------------------------------------------
r1202259 | pquerna | 2011-11-15 16:52:59 +0100 (Tue, 15 Nov 2011) | 2 lines

Use apr_pollset_wakeup to ensure that the listener thread will process
most enqueue'd events quickly

------------------------------------------------------------------------
r1202258 | pquerna | 2011-11-15 16:52:00 +0100 (Tue, 15 Nov 2011) | 2 lines

Because the pollset is now only mutated from the event thread, we no
longer need the APR_POLLSET_THREADSAFE flag for the event_pollset

------------------------------------------------------------------------
r1202257 | pquerna | 2011-11-15 16:51:03 +0100 (Tue, 15 Nov 2011) | 2 lines

Create a new lock free circular queue, and use it in the EventMPM to
remove the timeout mutex that was wrapping both timeout queue operations
and pollset operations.

------------------------------------------------------------------------
r1202256 | pquerna | 2011-11-15 16:50:09 +0100 (Tue, 15 Nov 2011) | 3 lines

Instead of disabling the listening sockets from the pollset when under
load, just stop calling the accept call, but leave the sockets in the
pollset.


Regards,

Rainer


minfrin at sharp

Jan 31, 2012, 7:17 AM

Post #2 of 17 (1116 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31 Jan 2012, at 5:07 PM, Rainer Jung wrote:

> 6) mod_cache
> ============
>
> Applied to 2.4.x but not in trunk:
>
> r1208384 | minfrin | 2011-11-30 12:21:43 +0100 (Wed, 30 Nov 2011) | 4 lines
>
> mod_cache: Revert http://svn.apache.org/viewvc?view=revision&revision=1070179
> as per the following thread:
> http://www.gossamer-threads.com/lists/apache/dev/395830?do=post_view_threaded#395830
>
> ------------------------------------------------------------------------
> r1208824 | minfrin | 2011-11-30 23:00:43 +0100 (Wed, 30 Nov 2011) | 4 lines
>
> Backport:
> mod_cache: Apply the API change that allows future mod_cache providers to
> invalidate cache entries, which will fix PR15868.
>
>
> Should both be ported forwards?

Both v2.4 and trunk have the same API signature as intended (no diff between mod_cache.h on v2.4 and trunk), is this an actual difference you've just found, or is this just following the commit log?

Regards,
Graham
--
Attachments: smime.p7s (4.26 KB)


rainer.jung at kippdata

Jan 31, 2012, 7:43 AM

Post #3 of 17 (1118 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31.01.2012 16:17, Graham Leggett wrote:
> On 31 Jan 2012, at 5:07 PM, Rainer Jung wrote:
>
>> 6) mod_cache
>> ============
>>
>> Applied to 2.4.x but not in trunk:
>>
>> r1208384 | minfrin | 2011-11-30 12:21:43 +0100 (Wed, 30 Nov 2011) | 4 lines
>>
>> mod_cache: Revert http://svn.apache.org/viewvc?view=revision&revision=1070179
>> as per the following thread:
>> http://www.gossamer-threads.com/lists/apache/dev/395830?do=post_view_threaded#395830
>>
>> ------------------------------------------------------------------------
>> r1208824 | minfrin | 2011-11-30 23:00:43 +0100 (Wed, 30 Nov 2011) | 4 lines
>>
>> Backport:
>> mod_cache: Apply the API change that allows future mod_cache providers to
>> invalidate cache entries, which will fix PR15868.
>>
>>
>> Should both be ported forwards?
>
> Both v2.4 and trunk have the same API signature as intended (no diff between mod_cache.h on v2.4 and trunk), is this an actual difference you've just found, or is this just following the commit log?

All the items listed are actual code differences. The log info was the
shortest way to explain the differences. I tried hard to verify, that
the differences I've seen are actually the ones generatde by these
missing commits.

In this case check

modules/cache/cache_storage.c
modules/cache/cache_storage.h
modules/cache/mod_cache.c

for differences.

Regards,

Rainer


minfrin at sharp

Jan 31, 2012, 8:17 AM

Post #4 of 17 (1115 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31 Jan 2012, at 5:43 PM, Rainer Jung wrote:

> All the items listed are actual code differences. The log info was the shortest way to explain the differences. I tried hard to verify, that the differences I've seen are actually the ones generatde by these missing commits.
>
> In this case check
>
> modules/cache/cache_storage.c
> modules/cache/cache_storage.h
> modules/cache/mod_cache.c
>
> for differences.

The code in v2.4 is correct. The code on trunk still has work outstanding to address cache invalidation, an issue that is an edge case in HTTP and needs more work on it.

Regards,
Graham
--
Attachments: smime.p7s (4.26 KB)


rainer.jung at kippdata

Jan 31, 2012, 8:37 AM

Post #5 of 17 (1113 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31.01.2012 17:17, Graham Leggett wrote:
> On 31 Jan 2012, at 5:43 PM, Rainer Jung wrote:
>
>> All the items listed are actual code differences. The log info was the shortest way to explain the differences. I tried hard to verify, that the differences I've seen are actually the ones generatde by these missing commits.
>>
>> In this case check
>>
>> modules/cache/cache_storage.c
>> modules/cache/cache_storage.h
>> modules/cache/mod_cache.c
>>
>> for differences.
>
> The code in v2.4 is correct. The code on trunk still has work outstanding to address cache invalidation, an issue that is an edge case in HTTP and needs more work on it.

So:

[ ] leave trunk as is, i.e. do not forward port the changes that are in
2.4 but not in trunk

[ ] sync trunk with 2.4 because that's a better baseline for adding
improvements

[ ] something else (what?)

Rainer


jim at jaguNET

Jan 31, 2012, 8:38 AM

Post #6 of 17 (1107 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

Thx for digging into this!

On Jan 31, 2012, at 10:07 AM, Rainer Jung wrote:

> I backported some trunk changes to 2.4.x (mostly cosmetic ones) and a few changes also in the other direction to keep code changes small in parts were there are still no functional changes.
>
> A few backports are open, because I'm not sure, whether we want to backport. I left out the obvious changes (serf, apreq and similar), and also the changes related to the recent core filter improvements, but the below ones are not obvious to me. Comments on them welcome:
>
> 1) mod_reqtimeout
> =================
>
> r1202255 | pquerna | 2011-11-15 16:49:19 +0100 (Tue, 15 Nov 2011) | 1 line
> disable mod_reqtimeout if not configured
>
> It looks like mod_reqtimeout is now inactive by default in trunk, but ses some builtin default values in 2.4.x. Is that what we want? I'd expected that if we have it automatically use default values when loaded in 2.4.x, we would want the same behaviour in trunk.
>

I'd prefer we keep the 2.4 behavior, but am happy with any.
>
> 2) log tags
> ===========
>
> r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 lines
> Add APLOGNO() macro for unique tags for every log message.
> Add some scripts to make adding these tags easier.
>
> This has only been backported partially. The directory docs/log-message-tags is mising in 2.4.x as well as the update-log-tags and update-log-msg-tags targets in Makefile.
>
>

Ugg... +1 on these

> 4) mod_proxy_html
> =================
>
> r1200556 | jorton | 2011-11-10 22:21:03 +0100 (Thu, 10 Nov 2011) | 3 lines
>
> * modules/filters/mod_proxy_html.c: Fix various code style issues. Use
> apr_is* ctype macro wrappers.
>
>
> I guess we want that also in 2.4.x.
>

+1

>
> 5) mod_authnz_ldap
> ==================
>
> r1231257 | covener | 2012-01-13 20:18:03 +0100 (Fri, 13 Jan 2012) | 3 lines
>
> whitespace only: shift a block refactored in r1231255 over 8 spaces.
>
>
> r1231255 | covener | 2012-01-13 20:16:50 +0100 (Fri, 13 Jan 2012) | 5 lines
>
> *) mod_authnz_ldap: Don't try a potentially expensive nested groups
> search before exhausting all AuthLDAPGroupAttribute checks on the
> current group. PR52464
>

Is it applicable?

> 7) .htaccess handling
> =====================
>
> ------------------------------------------------------------------------
> r1229021 | niq | 2012-01-09 05:01:06 +0100 (Mon, 09 Jan 2012) | 5 lines
>
> Core configuration: add AllowOverride option to treat syntax
> errors in .htaccess as non-fatal.
> PR 52439
>
>
+1


jim at jaguNET

Jan 31, 2012, 8:44 AM

Post #7 of 17 (1108 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Jan 31, 2012, at 11:38 AM, Jim Jagielski wrote:
>
> Is it applicable?
>
>> 7) .htaccess handling
>> =====================
>>
>> ------------------------------------------------------------------------
>> r1229021 | niq | 2012-01-09 05:01:06 +0100 (Mon, 09 Jan 2012) | 5 lines
>>
>> Core configuration: add AllowOverride option to treat syntax
>> errors in .htaccess as non-fatal.
>> PR 52439

Looks like it lacks docs... Will update.


minfrin at sharp

Jan 31, 2012, 8:44 AM

Post #8 of 17 (1109 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31 Jan 2012, at 6:37 PM, Rainer Jung wrote:

> So:
>
> [ ] leave trunk as is, i.e. do not forward port the changes that are in 2.4 but not in trunk
>
> [ ] sync trunk with 2.4 because that's a better baseline for adding improvements
>
> [ ] something else (what?)

Trunk has the most up to date code which will see further changes ongoing, and the v2.4 code doesn't contain anything that isn't in trunk already, so no forward porting is necessary that I am aware of. In other words:

[ ] Do nothing other than continue the improvements on trunk, as usual.

Regards,
Graham
--
Attachments: smime.p7s (4.26 KB)


ruediger.pluem at vodafone

Jan 31, 2012, 8:47 AM

Post #9 of 17 (1110 views)
Permalink
RE: Questions on open ports between trunk and 2.4.x [In reply to]

> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung [at] kippdata]
> Sent: Dienstag, 31. Januar 2012 17:37
> To: dev [at] httpd
> Subject: Re: Questions on open ports between trunk and 2.4.x
>
> On 31.01.2012 17:17, Graham Leggett wrote:
> > On 31 Jan 2012, at 5:43 PM, Rainer Jung wrote:
> >
> >> All the items listed are actual code differences. The log info was
> the shortest way to explain the differences. I tried hard to verify,
> that the differences I've seen are actually the ones generatde by these
> missing commits.
> >>
> >> In this case check
> >>
> >> modules/cache/cache_storage.c
> >> modules/cache/cache_storage.h
> >> modules/cache/mod_cache.c
> >>
> >> for differences.
> >
> > The code in v2.4 is correct. The code on trunk still has work
> outstanding to address cache invalidation, an issue that is an edge case
> in HTTP and needs more work on it.
>
> So:
>
> [ X ] leave trunk as is, i.e. do not forward port the changes that are in
> 2.4 but not in trunk


I follow Grahams arguments here.

Regards

Rüdiger


nick at webthing

Jan 31, 2012, 9:04 AM

Post #10 of 17 (1106 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Tue, 31 Jan 2012 11:44:07 -0500
Jim Jagielski <jim [at] jaguNET> wrote:


> >> 7) .htaccess handling
> >> =====================
> >>
> >> ------------------------------------------------------------------------
> >> r1229021 | niq | 2012-01-09 05:01:06 +0100 (Mon, 09 Jan 2012) | 5 lines
> >>
> >> Core configuration: add AllowOverride option to treat syntax
> >> errors in .htaccess as non-fatal.
> >> PR 52439
>
> Looks like it lacks docs... Will update.
>
Ouch! (fx: bows head in shame).

I guess I must've hesitated after nd's comment in bugzilla.
Will do it within 24 hours, unless you got there first.

--
Nick Kew


rainer.jung at kippdata

Jan 31, 2012, 9:09 AM

Post #11 of 17 (1108 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31.01.2012 17:38, Jim Jagielski wrote:
>> 5) mod_authnz_ldap
>> ==================
>>
>> r1231257 | covener | 2012-01-13 20:18:03 +0100 (Fri, 13 Jan 2012) | 3 lines
>>
>> whitespace only: shift a block refactored in r1231255 over 8 spaces.
>>
>>
>> r1231255 | covener | 2012-01-13 20:16:50 +0100 (Fri, 13 Jan 2012) | 5 lines
>>
>> *) mod_authnz_ldap: Don't try a potentially expensive nested groups
>> search before exhausting all AuthLDAPGroupAttribute checks on the
>> current group. PR52464
>>
>
> Is it applicable?

svn technically yes, if applied in numeric order (and ignoring CHANGES).

Does it make sense? It only changes modules/aaa/mod_authnz_ldap.c and
there's no API change involved. So IMHO it would make sense to backport
unless Eric plans to revert the change in trunk or finds it to risky.

Regards,

Rainer


jim at jaguNET

Jan 31, 2012, 9:21 AM

Post #12 of 17 (1111 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Jan 31, 2012, at 11:47 AM, Plüm, Rüdiger, VF-Group wrote:

>
>
>> -----Original Message-----
>> From: Rainer Jung [mailto:rainer.jung [at] kippdata]
>> Sent: Dienstag, 31. Januar 2012 17:37
>> To: dev [at] httpd
>> Subject: Re: Questions on open ports between trunk and 2.4.x
>>
>> On 31.01.2012 17:17, Graham Leggett wrote:
>>> On 31 Jan 2012, at 5:43 PM, Rainer Jung wrote:
>>>
>>>> All the items listed are actual code differences. The log info was
>> the shortest way to explain the differences. I tried hard to verify,
>> that the differences I've seen are actually the ones generatde by these
>> missing commits.
>>>>
>>>> In this case check
>>>>
>>>> modules/cache/cache_storage.c
>>>> modules/cache/cache_storage.h
>>>> modules/cache/mod_cache.c
>>>>
>>>> for differences.
>>>
>>> The code in v2.4 is correct. The code on trunk still has work
>> outstanding to address cache invalidation, an issue that is an edge case
>> in HTTP and needs more work on it.
>>
>> So:
>>
>> [ X ] leave trunk as is, i.e. do not forward port the changes that are in
>> 2.4 but not in trunk
>
>
> I follow Grahams arguments here.
>

+1


jim at jaguNET

Jan 31, 2012, 9:26 AM

Post #13 of 17 (1106 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Jan 31, 2012, at 10:07 AM, Rainer Jung wrote:
>
> 9) Event MPM
> ============
>
> I think everything apart from Paul's new queue has been backported, but please double check this list:
>

I believe you are correct and the diffs seem to show that the
main deltas are related to the Q. Also, from what I see, adding
that new Q effort to 2.4.x later on wouldn't require a bump, so
we're OK on that.


jim at jaguNET

Jan 31, 2012, 9:32 AM

Post #14 of 17 (1109 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

Stefan, as the main proponent of the APLOG changes, do you have
cycles to review and complete the below??

On Jan 31, 2012, at 10:07 AM, Rainer Jung wrote:
> 2) log tags
> ===========
>
> r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 lines
> Add APLOGNO() macro for unique tags for every log message.
> Add some scripts to make adding these tags easier.
>
> This has only been backported partially. The directory docs/log-message-tags is mising in 2.4.x as well as the update-log-tags and update-log-msg-tags targets in Makefile.


sf at sfritsch

Jan 31, 2012, 1:11 PM

Post #15 of 17 (1108 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Tuesday 31 January 2012, Jim Jagielski wrote:
> Stefan, as the main proponent of the APLOG changes, do you have
> cycles to review and complete the below??
>
> On Jan 31, 2012, at 10:07 AM, Rainer Jung wrote:
> > 2) log tags
> > ===========
> >
> > r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3
> > lines Add APLOGNO() macro for unique tags for every log message.
> > Add some scripts to make adding these tags easier.
> >
> > This has only been backported partially. The directory
> > docs/log-message-tags is mising in 2.4.x as well as the
> > update-log-tags and update-log-msg-tags targets in Makefile.

This is intentional and not for backport. The log tags should be
consistent between trunk and the branches, so there can be only one
"docs/log-message-tags/next-number" file, and that resides in trunk.
That means if an error message is introduced in 2.4 but not in trunk,
the next-number file in trunk should be updated.

But there should probably be a docs/log-message-tags/README file in
2.4 that explains this. I will write something when I have time. But
as a non-code change, this is not that urgent.


sf at sfritsch

Jan 31, 2012, 1:23 PM

Post #16 of 17 (1112 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On Tuesday 31 January 2012, Rainer Jung wrote:

> 1) mod_reqtimeout
> =================
>
> r1202255 | pquerna | 2011-11-15 16:49:19 +0100 (Tue, 15 Nov 2011) |
> 1 line disable mod_reqtimeout if not configured
>
> It looks like mod_reqtimeout is now inactive by default in trunk,
> but ses some builtin default values in 2.4.x. Is that what we
> want? I'd expected that if we have it automatically use default
> values when loaded in 2.4.x, we would want the same behaviour in
> trunk.

This should be reverted in trunk to behave as in 2.4. Pauls argument
was that it reduces performance but IIRC we later agreed that we
should optimize mod_reqtimeout instead. This causes less grief for
users than a behavor change during 2.4.


> 3) Recent install optimization
> ==============================
>
> r1237447 | sf | 2012-01-29 21:11:55 +0100 (Sun, 29 Jan 2012) | 11
> lines
>
> Install multiple files per install.sh invocation
>
> Libtool and BSD install support installing several files in one
> run. Add support to install.sh and instdso.sh, too.
> Replace for-loops in the Makefiles.
>
> This reduces 'make install' time by approx. 50% because we save
> lots of calls to the huge libtool shell script.
>
> The AIX-specific magic in instdso.sh could use some testing.
>
>
> Backport?

This is too new. Backport it if it hasn't caused any problems in a
month or two. Or not at all, it's mainly useful for developers that do
"make install" all the time ;-)

> 4) mod_proxy_html
> =================
>
> r1200556 | jorton | 2011-11-10 22:21:03 +0100 (Thu, 10 Nov 2011) |
> 3 lines
>
> * modules/filters/mod_proxy_html.c: Fix various code style issues.
> Use apr_is* ctype macro wrappers.
>
>
> I guess we want that also in 2.4.x.

+1

> 7) .htaccess handling
> =====================
>
> -------------------------------------------------------------------
> ----- r1229021 | niq | 2012-01-09 05:01:06 +0100 (Mon, 09 Jan 2012)
> | 5 lines
>
> Core configuration: add AllowOverride option to treat syntax
> errors in .htaccess as non-fatal.
> PR 52439

+/-0
Not sure that it is that a good idea, but if others are in favor,
that's fine.

> 8) ErrorLog directory checking
> ==============================
>
> r1225199 | sf | 2011-12-28 15:54:49 +0100 (Wed, 28 Dec 2011) | 6
> lines
>
> Check during configtest that the directories for error logs exist
>
> Testing under Windows is welcome
>
> PR: 29941

+1

This has been tested under Windows in the mean-time, but the identical
check for the access logs is still missing. That's no reason not to
backport this one, though.

> 9) Event MPM
> ============
>
> I think everything apart from Paul's new queue has been backported,
> but please double check this list:

Looks good. As a way forward I would suggest to make a branch from
Pauls's changes and revert trunk to 2.4's behavior. Then small
improvements could be prepared in trunk and the big redesign can be
done in that branch.


I want to add my own suggestion, this is unlikely to break something
unreleated:

10) Display registered providers in mod_info
============================================
r1225798:
Author: Stefan Fritsch <sf [at] apache>
Date: Fri Dec 30 10:55:00 2011 +0000

Add new ap_list_provider_groups() API for mod_info

r1225799:
Author: Stefan Fritsch <sf [at] apache>
Date: Fri Dec 30 11:00:31 2011 +0000

Display registered providers

While we are still CTR, I have been hesitant to introduce API changes
into 2.4, lately. +1, anyone?


rainer.jung at kippdata

Jan 31, 2012, 2:18 PM

Post #17 of 17 (1107 views)
Permalink
Re: Questions on open ports between trunk and 2.4.x [In reply to]

On 31.01.2012 22:23, Stefan Fritsch wrote:
> On Tuesday 31 January 2012, Rainer Jung wrote:
>
>> 1) mod_reqtimeout
>> =================

Now trunk is made consistent with 2.4.x (module is active with default
values if loaded but not explicitely configured). r1238826 (sf).

>> 2) log tags
>> ===========

Stefan suggests to always backport the tags from trunk. So no tag
generation infrastructure needed in 2.4.x. He will add a README sometime.

>> 3) Recent install optimization
>> ==============================

Postponed due to Stefan's comment.

>> 4) mod_proxy_html
>> =================

Done

> 5) mod_authnz_ldap
> ==================

Waiting for comment from Eric.

> 6) mod_cache
> ============

Consensus currently is, that no change is needed for 2.4.x. Delta to
trunk is intentional.

>> 7) .htaccess handling
>> =====================

Done (Jim).

>> 8) ErrorLog directory checking
>> ==============================

Done (Stefan).

>> 9) Event MPM
>> ============

Jim and Stefan agree, that there's nothing to do for 2.4.x now.

> 10) Display registered providers in mod_info
> ============================================
> r1225798:
> Author: Stefan Fritsch<sf [at] apache>
> Date: Fri Dec 30 10:55:00 2011 +0000
>
> Add new ap_list_provider_groups() API for mod_info
>
> r1225799:
> Author: Stefan Fritsch<sf [at] apache>
> Date: Fri Dec 30 11:00:31 2011 +0000
>
> Display registered providers
>
> While we are still CTR, I have been hesitant to introduce API changes
> into 2.4, lately. +1, anyone?

+1 from me.

Actually that one was one of the remaining deltas I forgot to propose.

Some of them are IMHO consensus to keep in trunk only currently:

mod_noloris, mod_firehose, mod_policy, apreq, mod_serf, simple mpm

Two more things are:

11) LUA compatibilty with Lua 5.2.0
===================================

There is a patch in trunk, but I wanted to check more thoroughly,
whether its the right way to do, so I didn't yet backport. Since Lua
5.2.0 is very recent, I think this is not pressing.

12) Scoreboard API change
=========================

When the recent security fix for the scoreboard was added, the change in
2.4 was slightly different from trunk, I think to avoid an API change.
If we are still free to change the API, it might be a good point to make
2.4 consistent with trunk:

apache% diff -u 2.4.x/include/scoreboard.h trunk/include/scoreboard.h
--- 2.4.x/include/scoreboard.h 2012-01-31 11:35:57.839995000 +0100
+++ trunk/include/scoreboard.h 2012-01-31 11:37:44.333200000 +0100
@@ -120,7 +120,6 @@
typedef struct {
int server_limit;
int thread_limit;
- ap_scoreboard_e sb_type;
ap_generation_t running_generation; /* the generation of children
which
* should still be serving
requests.
*/
apache% diff -u 2.4.x/server/scoreboard.c trunk/server/scoreboard.c
--- 2.4.x/server/scoreboard.c 2012-01-31 11:34:50.922649000 +0100
+++ trunk/server/scoreboard.c 2012-01-31 11:37:00.068548000 +0100
@@ -330,7 +330,7 @@
ap_init_scoreboard(sb_mem);
}

- ap_scoreboard_image->global->sb_type = scoreboard_type = sb_type;
+ scoreboard_type = sb_type;
ap_scoreboard_image->global->running_generation = 0;
ap_scoreboard_image->global->restart_time = apr_time_now();


Regards,

Rainer

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.