Am 23.01.2017 um 21:54 schrieb Stefan Eissing: > >> Am 22.01.2017 um 22:22 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> @icing: Any special expectation in mod_h2 with regard to mpm workers >> threads' lifetime (or keepalive connections that should stay alive for >> the configured limit)? >> I see that beam buckets make use of thread local storage/keys for >> locking, and that they also handle the double cleanup like eoc buckets >> did before 1.8.9, but can't follow all the paths yet. >> Maybe something to look at there? > > - With your help, mod_http2 1.8.9 simplified cleanup by triggering it by the > connection pool clean up only. That helped. The bucket beam still register > for pool cleanup which could be done without, but I think it's a good > failsafe. > - The thread local is used for recursive locking and, once the outermost lock > is released, are supposed to be NULL again. This I would like to eliminate > one day. > - the special handling for apr_files is gone as well. That was a work-around > when shared file buckets were transported through a bucket beam. No more. > Shared file buckets are copied now. Only file buckets with refcount == 1 are > beamed now. That makes the beam the sole controller of the lifetime and makes > setasides on the master connection work without special handling. > > I am not aware of any special expectations now. Almost all is triggered by > (parent) pool cleanups and is therefore more deterministic than before. The > only explicit destroy is done on finished streams and slave connections no > longer used. When the master conn disappears, all is deallocated as the force > wills it.
Thanks and + 1 - only two crashes in 48h. ,-) before i had around 2 per hour. Need some time to debug them. Don't have dumps yet. Is there an easier way to get core dumps than manually starting httpd while using systemd? ulimit -c unlimited httpd -k start Greets, Stefan > > Stefan Eissing > > <green/>bytes GmbH > Hafenstrasse 16 > 48155 Münster > www.greenbytes.de >
