Bug 43359

Summary: trunk EventMPM's graceful restart/stop are not graceful
Product: Apache httpd-2 Reporter: Takashi Sato <takashi.asfbugzilla>
Component: mpm_eventAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: major Keywords: PatchAvailable
Priority: P3    
Version: 2.5-HEAD   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Attachments: [incomplete] listener thread stop only listening
for trunk, implement a connection counter
conn counter using conn pool
for trunk

Description Takashi Sato 2007-09-12 03:00:52 UTC
I tested rev 574843 Event MPM.
While downloading a file, a graceful restart/stop kill a connection 
immediately.

I tested rev 327944 (before async write was merged) too, and no problem.
Comment 1 Takashi Sato 2007-10-02 08:36:10 UTC
See event.c line 1220 (on rev 574462).
Before async write was merged, process_socket was blocked.
After merged, it isn't blocked.
As a result, worker thread doesn't care whether any downloading continue.
Comment 2 Takashi Sato 2007-10-02 16:55:00 UTC
Not only worker thread but listener thread also needs to be patched.
Even if workers are alive if listener thread has exited workers can't get 
their jobs.
Comment 3 Takashi Sato 2007-10-05 09:54:39 UTC
(In reply to comment #1)
> See event.c line 1220 (on rev 574462).
> Before async write was merged, process_socket was blocked.
> After merged, it isn't blocked.
> As a result, worker thread doesn't care whether any downloading continue.

That's wrong.
The worker threads exit after the listener thread exits.
Comment 4 Takashi Sato 2007-10-05 09:56:11 UTC
Created attachment 20925 [details]
[incomplete] listener thread stop only listening

This patch makes:

If graceful stop/restart performs, listener thread stops listening sockets, and
continue to poll sockets that was already accepted.

But this patch is incomplete... Listener is still alive when there's no
clients. I can't find how to know how many clients remains.
Comment 5 Takashi Sato 2007-10-06 00:01:09 UTC
Created attachment 20932 [details]
for trunk, implement a connection counter

This seems to work.
Comment 6 Paul Querna 2007-10-06 00:40:05 UTC
Perhaps tie the apr_atomic_dec32() into a cleanup function,  on connection pool?

using apr_pool_cleanup_register:
http://apr.apache.org/docs/apr/1.2/group___pool_cleanup.html#g6bdb28224dfe08160cbe3ba6b22dcbd7
Comment 7 Takashi Sato 2007-10-06 09:00:39 UTC
(In reply to comment #6)
> Perhaps tie the apr_atomic_dec32() into a cleanup function,  on connection 
pool?

very Good idea
Comment 8 Takashi Sato 2007-10-08 02:58:29 UTC
Created attachment 20941 [details]
conn counter using conn pool

The connecton counter is decremented on a cleanup function on connection pool.
Comment 9 Paul Querna 2007-10-08 11:41:53 UTC
I think the patch is almost perfect. I think apr_thread_join should still be
called for the listener thread though?  In join_workers, I think you should
still join() on the listener, after all the worker threads are joined?
Comment 10 Takashi Sato 2007-10-10 00:47:18 UTC
(In reply to comment #9)
> I think the patch is almost perfect
not perfect I think.
I don't understand the code about scoreboard and 
perform_idle_server_maintenance enough.

> I think apr_thread_join should still be
> called for the listener thread though?

The workers never exit before the listener exits at graceful stop/restart,
but at ungraceful stop/restart the workers can.
And even at graceful, should apr_thread_join.
Looking back, I just wanted to suppress "[debug] the listener thread didn't 
exit".
I've reverted partially join_workers().
Comment 11 Takashi Sato 2007-10-10 01:07:20 UTC
Created attachment 20950 [details]
for trunk
Comment 12 Stefan Fritsch 2011-06-18 13:21:48 UTC
Committed in r1137182, thanks for the patch