Summary: | trunk EventMPM's graceful restart/stop are not graceful | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Takashi Sato <takashi.asfbugzilla> |
Component: | mpm_event | Assignee: | 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
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. 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. (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. 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.
Created attachment 20932 [details]
for trunk, implement a connection counter
This seems to work.
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 (In reply to comment #6) > Perhaps tie the apr_atomic_dec32() into a cleanup function, on connection pool? very Good idea Created attachment 20941 [details]
conn counter using conn pool
The connecton counter is decremented on a cleanup function on connection pool.
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? (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(). Created attachment 20950 [details]
for trunk
Committed in r1137182, thanks for the patch |