On Tue, Jul 12, 2016 at 3:37 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote:
> > > Am 11.07.2016 um 17:38 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > > > On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > > In https://bz.apache.org/bugzilla/show_bug.cgi?id=59840 the issue crept > up that StdEnvVars makes concurrent access to the SSL context when HTTP/2 > is in place. > > > > The question is: how do we want to fix this? > > > > The general theme is that a module needs to perform some action on a > connection, sees that it is a slave connection and accesses the master > instead. Such a module needs to be aware that access to master may happen > in parallel with other request. > > > > Should we let each such module care for it on its own or do we want to > provide a way to access the master connection in a mutex protected way? > > > > Rather than a mutex, which would become an issue because all master > access > > to the context would require blocking, is there a way we can allow a > module to > > perform its (hopefully swift) processing on the master thread? Send a > metadata > > bucket to the master asking for a function to be invoked? > > Hmm, interesting idea. Of course, there would still be a mutex involved in > handling such a query, but maybe it can be done more elegant than mutexing > all accesses to structures everywhere. > > One way to look at this is that information retrieval from slave to master > is something like a GET and that information injection into the master conn > is something like a POST. So, effectively (and not necessarily in HTTP wire > format), a slave connection would to a > > GET /ssl/StdEnvVars > > to retrieve the map. Which would, the first time, get added to the > incoming queue on the master thread, be answered, slave thread awoken again > and processing continues. This would be cached for future queries, so that > slaves can access it without being put to sleep. > > We could use our famous HOOK infrastructure so that modules can register > their own handlers for such information. We'd only need to nail down the > general semantics and the data format for interchange. Something like a > const apr_table_t would probably work. It would need to be readonly and > allow concurrent use. > The problem I encountered in mod_ftp was unbounded memory consumption in the control connection (similar schema to mod_http2 master/child)... In the mod_ftp case, it was login credentials. A unique pool off of the connection that could be cleared on a new login was necessary to keep us from consuming more and more pool on each login reattempt. Same will happen here, that apr_table_t of ssl envvars will need to survive until all requests running off of that list of connection strings are complete, and then released. Maybe a simple apr_atomic_inc32/dec32 would suffice for a ref count, based on a cleanup registered on the request pool? In any case, the request should use the result table it requested, and not some shared pointer in the conn_rec.
