Re: blocking listener thread during SSL shutdown

[Frank Meier]

On 12/04/17 21:30, Ruediger Pluem wrote:

A debug build which states the line numbers would be more helpful here. What I 
can conclude so far by looking at the
code is that it does not wait on the client to sent something but that it does 
wait on the socket to accept data for
sending.
So possibly the problem will go away if you fiddle around a little bit with the 
SendBufferSize.
Unfortunately I do no longer have access to the system, so we would have 
to stick to a theoretical approach :-(. Maybe an increase in 
SendBufferSize would mitigate the Issue, but in my opinion the code 
should be written that it could not block even the send buffer is full.
Or The listener thread should dispatch the closing to a worker thread, 
so it gets not distracted from handling new connections.


Frank Meier
Senior Software Engineer

--
frank.me...@ergon.ch, Phone: +41 44 268 87 35
Ergon Informatik AG, Merkurstrasse 43, CH-8032 Zürich
http://www.ergon.ch

__
e r g o n smart people - smart software

Re: Fixing more OpenSSL callback crashes

[Tsuyoshi SASAMOTO]

>...oh. So errno is actually threadsafe, but its "address" is the same in
>every thread? Interesting.

MT-Safe errno of Solaris is implemented as a function,
so its address is same but the value is different.
cf. https://src.illumos.org/source/xref/illumos-gate/usr/src/head/errno.h

https://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libc/port/gen/errno.c


Tsuyoshi SASAMOTO
nazon...@miobox.jp

Re: blocking listener thread during SSL shutdown

[Frank Meier]

On 12/04/17 21:37, Eric Covener wrote:

Any chance the logs also report write timeouts that precede this?  Are
there "similar" threads waiting for writability of actual response
data (e.g. ap_invoke_handler in the stack)
I'm not aware of any write timeouts in the httpd logs but then, this was 
a productive system with a "low" log level. Unfortunately I have no 
longer access to them.
I still have the stacks (printed with gstack) of all the HTTPD 
processes, there I see most of the worker threads are idle (waiting in 
ap_queue_pop_something ()), but some are indeed also blocked in a poll() 
triggered by apr_rflush() (flushing data to the client). But since they 
are worker threads this is just normal behaviour, I'd say.
The problem here is that the listener thread is blocked, which should 
never happen. I think if the listener thread is calling a function that 
might block, it should dispatch this task to another thread instead 
doing it itself. Or the function start_lingering_close_nonblocking() 
*really* has to be nonblocking.

Re: svn commit: r1791192 - /httpd/httpd/branches/2.4.x/support/abs.mak

[Gregg Smith]

On 4/12/2017 9:12 PM, William A Rowe Jr wrote:

On Wed, Apr 12, 2017 at 5:31 PM,   wrote:

Author: gsmith
Date: Wed Apr 12 22:31:15 2017
New Revision: 1791192

URL: http://svn.apache.org/viewvc?rev=1791192=rev
Log:
Add another include since applink.c has been moved in
the OpenSSL source. More info:
http://marc.info/?t=14919286431=1=2

Modified:
httpd/httpd/branches/2.4.x/support/abs.mak

Modified: httpd/httpd/branches/2.4.x/support/abs.mak
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/abs.mak?rev=1791192=1791191=1791192=diff
==
--- httpd/httpd/branches/2.4.x/support/abs.mak (original)
+++ httpd/httpd/branches/2.4.x/support/abs.mak Wed Apr 12 22:31:15 2017
@@ -28,7 +28,7 @@ NULL=nul
 !IF "$(_HAVE_OSSL110)" == "1"
 SSLCRP=libcrypto
 SSLLIB=libssl
-SSLINC=/I ../srclib/openssl/include
+SSLINC=/I ../srclib/openssl/include /I ../srclib/openssl/ms


Question (untested)... does this work for local builds, since ms is not
in the include  scope?


No, will revert.

It will have to be done as a prebuild step, placing a copy into 
include/openssl.