[Info-vax] New OpenSSL update from HP

[Jan-Erik Soderholm]

Simon Clubley skrev den 2015-06-16 12:59:
> On 2015-06-15, David Froble <davef at tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> On 2015-06-15, David Froble <davef at tsoft-inc.com> wrote:
>>>> Ok, I've never written a web server, yet.  If I was to do so, I'd
>>>> seriously look at detached processes rather than sub-processes.  Why?
>>>> Because once you assign the worker process a task, perhaps you'd want it
>>>> to complete, regardless of whatever the web server does.
>>>>
>>>
>>> What happens if you need to shutdown/restart the web server and need
>>> to _guarantee_ that all related processes have terminated as part of
>>> of the shutdown process ?
>>>
>>
>> Couple of issues there.
>>
>> First, a worker process lifetime should be measured in fractions of a
>> second, or a couple seconds at most.
>>
>> The listener could keep track of the PIDs that it created, and a
>> shutdown command could terminate them in the chosen manner.
>>
>> That said, it's been my impression that web server transactions are
>> stateless, (if I understand that term), and usually occur in a rather
>> short time period, such as a fraction of a second.  Do you have examples
>> of when a worker process would remain active for an extended period of
>> time?  I'm curious.
>>
>
> I was responding to the specific technical issues around your desire
> to make them detached processes instead of subprocesses.
>
> Also, connections remain open by default after the initial request has
> been completed; these are called persistent connections. See:
>
> 	https://en.wikipedia.org/wiki/HTTP_persistent_connection
>
> In order to implement this functionality, your detached process would
> have to remain around after the initial request has completed and they
> would not automatically die (unlike with subprocesses) if the parent
> web server process croaked due to some internal bug.
>
> Simon.
>

And besides of "HTTP_persistent_connections", the web server can have its
own rules for how long a server process keeps alive waiting for new
requests (from *any* client). The Python RTE processes that WASD manage
has a timeout of 5 minutes or something like that. That in it self has
nothing to do with persisting HTTP connections. Fully configurable
in the WASD config files, of course...

Jan-Erik.