On Fri, Jun 25, 2021 at 03:50:33PM -0700, Roy T. Fielding wrote:
> I was about to update the site config so that it wouldn't send notices
> to dev, but I don't know whether they should instead go to cvs, docs, or
> a new list (like notices at httpd). Any opinions?
We already have notifications@ w
Hi,
what do you think about adding a hook for MPMQ state changes?
AP_MPMQ_STARTING -> AP_MPMQ_RUNNING -> AP_MPMQ_STOPPING
Background: several module monitor the state to abort a loop early to not delay
a child exit unnecessarily. However there seems to be no notification mechanism
available (o
On 6/28/21 10:12 AM, Joe Orton wrote:
> On Fri, Jun 25, 2021 at 03:50:33PM -0700, Roy T. Fielding wrote:
>> I was about to update the site config so that it wouldn't send notices
>> to dev, but I don't know whether they should instead go to cvs, docs, or
>> a new list (like notices at httpd). A
On Mon, Jun 28, 2021 at 10:28 AM Stefan Eissing
wrote:
>
> what do you think about adding a hook for MPMQ state changes?
>
> AP_MPMQ_STARTING -> AP_MPMQ_RUNNING -> AP_MPMQ_STOPPING
Fine by me, we just need to make sure that the hooks are not called
from signal handlers (e.g. MPM prefork sets AP_M
> Am 28.06.2021 um 11:18 schrieb Yann Ylavic :
>
> On Mon, Jun 28, 2021 at 10:28 AM Stefan Eissing
> wrote:
>>
>> what do you think about adding a hook for MPMQ state changes?
>>
>> AP_MPMQ_STARTING -> AP_MPMQ_RUNNING -> AP_MPMQ_STOPPING
>
> Fine by me, we just need to make sure that the ho
On Mon, Jun 28, 2021 at 12:56 PM Stefan Eissing
wrote:
>
> Right. Let's say we restrict this to changes in child processes. As in:
>
> 1. AP_DECLARE_HOOK(void,child_running,(apr_pool_t *pchild, server_rec *s))
> 2. AP_DECLARE_HOOK(void,child_stopping,(apr_pool_t *pchild, server_rec *s,
> int grac
When the MPM event/worker is restarting, it first signals the
children's processes to stop (via POD), then reload the configuration,
and finally start the new generation.
This may be problematic when the reload takes some time to complete
because incoming connections are no longer processed.
A mod
Hi -
Greg and discussed this situation further and I misinterpreted a comment.
I reverted this change.
Regards,
Dave
> On Jun 26, 2021, at 9:17 AM, Dave Fisher wrote:
>
> FYI -
>
> The regeneration of vulnerability reports is now a manual exercise. On review
> with Infra it was decided that
I spot checked and it looked good to me. Thanks Dave!
Can anyone else review please so we can cut over and get off the naughty list?
On Fri, Jun 25, 2021 at 1:13 PM Dave Fisher wrote:
>
> The Migration from CMS to ASF-Pelican is staged!
>
> https://httpd.staged.apache.org/ is ready.
>
> https:/
Nobody ever really gets off the naughty list...
On Mon, Jun 28, 2021 at 2:40 PM Eric Covener wrote:
> I spot checked and it looked good to me. Thanks Dave!
>
> Can anyone else review please so we can cut over and get off the naughty
> list?
>
> On Fri, Jun 25, 2021 at 1:13 PM Dave Fisher wrote
FYI - for the website the locations are controlled from
https://github.com/apache/httpd-site/blob/main/.asf.yaml
github:
features:
# Enable issue management
issues: true
notifications:
commits: c...@httpd.apache.org
issues: dev@httpd.apache.org
pullrequests: dev@httpd.apache.org
Just eyeballing it, but probably because it is doing fairly fragile string
matches into config to look for virtualhost configs to apply to the
request. Likely done as the lua_state may be reused across virtualhosts, so
different config from where it was created.
-Brian
On Tue, Jun 8, 2021 at 1:43
12 matches
Mail list logo