https://bz.apache.org/bugzilla/show_bug.cgi?id=61551

--- Comment #30 from Yann Ylavic <ylavic....@gmail.com> ---
(In reply to dferradal from comment #29)
> We have had the exact issue with another third-party module. All kinds of
> different versions of weblogic module mod_wl_24.

Daniel, is that with 2.4.27?
I keep asking this because there is a significant change in mpm_event starting
with 2.4.29 and related to how workers and graceful restart events have to wake
up the listener thread when it's polling (possibly indefinitely) for
connections.

This (current) PR is not related to the above change (because it happens with
2.4.27), but probably due to some third party module's processing hook which
does not report an expected connection state to mpm_event, while that used to
work with mpm_worker for instance.

So for your case to be relared to this PR, mod_wl (which I know nothing about)
should have a process_connection hook acting like this, and attachment 35510
should fix it.

> I resorted to set MaxConnectionsPerchild 0 and/or not ever do graceful
> restarts and set MaxSpareThreads to the same value as MaxRequestWorkers to
> avoid any kind of process/thread recycling and managed to work-around this
> issue successfully.

I'm not sure this (current) PR has to do with children recycling, I think it
could happen without.

> 
> I hope I get get as good info as Nic has provided soon but I can't reproduce
> it that easily.

Possibly more Bug 61786 's material then...

> Although you guys seem to have caught the issue already. Perhaps a parameter
> for timeout for gracefully finishing threads could be considered if possible
> for the future for buggy third party modules? Something like (in seconds):
> 
> GracefulTimeOut 300

Let's discuss this on dev@ if you wish, that's certainly not a fix for
processes stuck with no connections to handle...

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to