Re: Timetable for 2.2.26 release?
STATUS is clean and so far all tests on all my avail platforms pass. Let give it another day or 2 (since today is a US holiday) and then I'll do a T&R on Weds. On Nov 8, 2013, at 1:26 PM, Jim Jagielski wrote: > I'll RM 2.2.26... how does a T&R late next week sound? > > On Nov 8, 2013, at 12:44 PM, Ben Reser wrote: > >> Does anyone have a timetable for a 2.2.26 release? >> >> Subversion users have been running into the issues introduced in 2.2.25 and >> we've been pointing them at patches. Some but not all of the binaries >> floating >> around have been patched. It would be really nice to be able to have a httpd >> release to point them at. >> >> For instance this guy popped up yesterday: >> https://mail-archives.apache.org/mod_mbox/subversion-users/201311.mbox/%3C4A2A8BDDBE6EFE4199FB22121DB971B1A1B07E6B%40AAPLExchange.aapl.com.au%3E >> >> In the meantime I've posted this thread on the us...@subversion.apache.org >> list >> in an effort to help users: >> https://mail-archives.apache.org/mod_mbox/subversion-users/201311.mbox/%3C527C7AC3.5050906%40reser.org%3E >> >> The PR 55306 and PR 55397 changes that are accepted in the 2.2.x branch >> STATUS >> file are the fixes for these issues. >> >> I know that 2.4.7 is held up by waiting on APR 1.5 but the vast majority of >> Subversion users are still using 2.2.x. So in the meantime it'd be really >> nice >> if we could get the 2.2.x release done. I'd be happy to take on some of the >> work myself if someone can point me in the right directions. >> >
Re: persisting the slotmem (Was: Re: mod_proxy: maximum hostname length for workers)
Now in trunk and proposed for 2.4... On Nov 9, 2013, at 10:27 AM, Daniel Ruggeri wrote: > On 11/8/2013 12:42 PM, Jim Jagielski wrote: >> This has me thinking... we should likely do something to >> better error-check the store/restore aspects of slotmem. >> Even some sort of quick checksum would be better than >> what we have now. :/ >> >> Gotta mull this over a bit more. > > +1 to that. I couldn't imagine someone (or thing) would go muck with > that file... but stranger things have happened on MY file systems :-) > > -- > Daniel Ruggeri >
Re: RLIMIT_NPROC on Linux?
Eric Covener wrote: > I was looking at a typical apr_thread_create failure for creating a > large # of threads on a system, and the only solution was to increase > roots RLIMIT_NPROC as opposed to the (httpd.conf configured) "User" > limits I assume that you configured that via /etc/security/limits.conf? Regards Rüdiger
Re: mod_ssl: why do we flush on EOS in ssl_io_filter_output()?
On Mon, 4 Nov 2013, Graham Leggett wrote: > Looking a little bit deeper, we find the following: > > - The event MPM seems to want to perform write completion on the very > last filter in the chain only, which seems completely arbitrary - why > should another filter (like mod_ssl) be prevented from running within > write completion? Doesn't make sense to me. Ideally we need to teach the > event MPM to run write completion on a class of filters, such as > AP_FTYPE_NETWORK, and make it a rule that network filters must be aware > of and are not allowed to block async MPMs. Given that in theory there > is only one AP_FTYPE_NETWORK filter (to my knowledge), this should be > backportable to v2.4. The filter calls during write completion are done in the worker threads. There is no strict requirement that they must not block. Of course, if they block, the advantage of write completion is lost. I think we should stay with this mode for the time being, because it will save a lot of trouble in case of badly behaved filters. Also, if encryption would be done in the async thread, the CPU processing that thread could become a bottleneck. In the medium term, we don't only want network filters to become eligible for write completion, but all filters. Think of a large text file being compressed with mod_deflate. Or a large file being processed with mod_include. I had the idea of inserting another buffering filter at the very start (let's call it edge_filter for now), which could then be called on write completion. It could somehow communicate with the core_output_filter to balance how much data is buffered on which end of the filter chain. For example, as long as core_output_filter has data buffered, it would write that with async write completion. When its buffer gets emtpy, it would call edge_filter to send some more data through the whole filter chain, including mod_ssl. If any in-between filter module blocks, then it would no worse than now, without write completion. But I think in many cases, none of the in-between filters would block, and we get write completion for many filters. Of course, so far this is only an idea and I haven't digged into the code to see if it's actually feasible. Do you see any immediate reason why it wouldn't work? > - mod_ssl defines itself as "AP_FTYPE_CONNECTION + 5", which looks to me > like mod_ssl really wants to be a network filter, not a connection > filter. If we were to teach the event MPM above to trigger network > filters, I propose that mod_ssl becomes a network filter following the > "not allowed to block async MPMs" rule (which it should do already > anyway). I have no idea ATM about the implications of changing that. BTW, mod_reqtimeout registers as AP_FTYPE_CONNECTION + 8. But it may make sense to integrate that into the core_output_filter.
Re: error log providers, multiple vhosts, mod_syslog
On Thu, 7 Nov 2013, Joe Orton wrote: > On Thu, Oct 17, 2013 at 12:33:50PM +, Plüm, Rüdiger, Vodafone Group wrote: > > Hmm. This points out another issue when using an error log provider for the > > main server log: > > We lose everything that the server or other programs like CGI-scripts write > > to the stderr FD as it > > is simply written to /dev/null. Don't we need to have a separate process in > > this case that > > like a piped logger reads from the reading end of the "stderr pipe" and > > writes it > > via ap_server_conf->errorlog_provider->writer to the log? > > Jumping in here... > > Actually there should be few cases where modules write to stderr, no? > I'm not sure we should even consider "writes to stderr get logged" a > valid part of the module API. "If you're not using ap_log_*error, > you're out of luck" is not totally unreasonable. I think LDAPLibraryDebug is one user of stderr going to the error log. As the logging is done by the ldap library, there is really no way to change it. But I guess it would be acceptable if that works only if logging to a file (as long as logging to a file can be enabled even if the normal logging goes somewhere else via an error log provider).
