On 04/12/2013 10:42 PM, Guenter Knauf wrote:
> On 10.04.2013 23:21, Guenter Knauf wrote:
>> On 10.04.2013 23:01, fua...@apache.org wrote:
>>> Author: fuankg
>>> Date: Wed Apr 10 21:01:51 2013
>>> New Revision: 149
>>>
>>> URL: http://svn.apache.org/r149
>>> Log:
>>> Put this backport for no
On 4/12/2013 2:32 PM, wr...@apache.org wrote:
> Author: wrowe
> Date: Fri Apr 12 19:32:55 2013
> New Revision: 1467433
>
> URL: http://svn.apache.org/r1467433
> Log:
> Belated explantion for druggeri
>
> Modified:
> httpd/httpd/branches/2.2.x/STATUS
>
> Modified: httpd/httpd/branches/2.2.x/STA
On Friday 12 of April 2013, Arkadiusz Miśkiewicz wrote:
> 6) possible solution - detect that sending dummy_connection data weren't
> processed by children by trying to read reply
>
> diff -ur httpd-2.4.4.org/server/mpm_unix.c httpd-2.4.4/server/mpm_unix.c
> --- httpd-2.4.4.org/server/mpm_unix.c 2
On 10.04.2013 23:21, Guenter Knauf wrote:
On 10.04.2013 23:01, fua...@apache.org wrote:
Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149
URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...
ok, onward with some mo
On 4/12/2013 10:43 AM, Guenter Knauf wrote:
I know; but I dont know if Gregg did a release or debug build;
I've heard a couple of times in the past that folks were not able to
re-create crash with debug builds but which happen with release builds;
that could f.e. explain why Daniel doesnt see th
On 11.04.2013 12:25, Guenter Knauf wrote:
well, another possible fix would be this one:
Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c(revision 1466743)
+++ modules/lua/lua_request.c(working copy)
@@ -120
On 4/12/2013 10:43 AM, Guenter Knauf wrote:
Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
On 11.04.2013 15:06, Daniel Gruno wrote:
On 04/11/2013 02:36 PM, Guenter Knauf wrote:
oh, and some more questions:
whats the benefit of having banner(), port() and started() as functions
(or methods)?
isnt it fine accessing these like f.e. r.filename?
r:put(r.banner) would be even shorter than r
Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
NetWare crashes the Windows httpd ...
Back
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf wrote:
> I've now tested on Windows, and I can see all previously mentioned
> issues there too; in addition the attached script which works fine on
> NetWare crashes the Windows httpd ...
Backtrace, please?
A strange idea, but did you happen to
On Friday 12 of April 2013, Eric Covener wrote:
> > diff -ur httpd-2.4.4.org/server/mpm_unix.c httpd-2.4.4/server/mpm_unix.c
> > --- httpd-2.4.4.org/server/mpm_unix.c 2012-07-03 21:38:58.0
> > +0200 +++ httpd-2.4.4/server/mpm_unix.c 2013-04-12
> > 09:14:58.282929959 +0200 @@ -604,7
> diff -ur httpd-2.4.4.org/server/mpm_unix.c httpd-2.4.4/server/mpm_unix.c
> --- httpd-2.4.4.org/server/mpm_unix.c 2012-07-03 21:38:58.0 +0200
> +++ httpd-2.4.4/server/mpm_unix.c 2013-04-12 09:14:58.282929959 +0200
> @@ -604,7 +604,17 @@
> len = strlen(data);
> }
>
> -
Tom Evans wrote:
> On Fri, Apr 12, 2013 at 7:18 AM, Lam, Eugene wrote:
>> Hi Kaspar,
>>
>> Thanks for digging up that thread. I still think SNI needs to be
>> considered, but not in the way I originally thought!
>>
>> On 4/10/13 9:43 PM, "Kaspar Brand" wrote:
>>
>> On 10.04.2013 02:49, Lam, Eu
On Fri, Apr 12, 2013 at 7:18 AM, Lam, Eugene wrote:
> Hi Kaspar,
>
> Thanks for digging up that thread. I still think SNI needs to be
> considered, but not in the way I originally thought!
>
> On 4/10/13 9:43 PM, "Kaspar Brand" wrote:
>
> On 10.04.2013 02:49, Lam, Eugene wrote:
>
> ssl_engine_io
On Thursday 11 of April 2013, Arkadiusz Miśkiewicz wrote:
> Hello,
>
> On apache 2.2.22, 2.2.23 and 2.4.4 I'm able to reproduce a problem
> where graceful restart takes very long time. Linux 3.7.10, glibc 2.17 here.
Summary of my findings
1) main process on gracefull restart calls
/* kill off t
15 matches
Mail list logo