Request and Response Object can be deleted at every time

[bzeller]

I openend this as a own issue. I came over it while stress testing the threading code
with autobench/httperf.
And i found 2 problems but they come both from the same source:

Httperf opens lots of connections at the same time and runs requests on the server.
Every request has a timeout and if the timeout is reached it just closes the socket.
This may be no problem with the non threaded version ( i didn't check yet) but in the
threaded version you have pending requests if the server load is high.
They are waiting in a queue, the problem is if they reach the connection timeout the
sockets are closed and deleted WHILE they are still waiting. Also we don't have
socket error handling code (a error maybe should emit some signal and close the
request).

This creates two problems:

1. If you call flush on a closed socket you get a SIGPIPE termination. HttpFileHandler runs into this because it does not enter the eventloop when writing
   multiple times to the socket. This can maybe be fixed with using
   waitForBytesWritten() instead of flush as the docs state. This will return false
   if a error occured.

2. The requests object are deleted behind the back of the application, i worked
   around this by using QPointer objects , so at least i know when they are gone.

The question is if we should think about a different approach than directly connecting
request objects to their deleteLater slot, so we can handle these things better.

[bzeller]

After thinking about this some more, i would propose a change where we put the Request objects inside QSharedPointers, where as long as the request is valid the HttpServer holds a copy. When the request is
invalid because the connection was closed, the server removes that copy. The request object itself will
stay as long as there are other copies out in the wild.

On second thought that would mean a source compatibility break, because that shared object of course
needs to be used everywhere , also in usercode. But maybe we could create something like a shared
backend of HttpServerRequest ( HttpTcpRequestBackend, HttpFCGIRequestBackend) that goes invalid
when the request was closed.

To make that happen we of course would need some state and error checking code in HttpServerRequest:

HttpServerRequest::isValid or HttpServerRequest::isAlive
HttpServerRequest::hasError
HttpServerRequest::error

and so on.

[vinipsmaker]

Httperf opens lots of connections at the same time and runs requests on the server.
Every request has a timeout and if the timeout is reached it just closes the socket.
This may be no problem with the non threaded version ( i didn't check yet) but in the
threaded version you have pending requests if the server load is high.
They are waiting in a queue, the problem is if they reach the connection timeout the
sockets are closed and deleted WHILE they are still waiting. Also we don't have
socket error handling code (a error maybe should emit some signal and close the
request).

The threaded abstraction can disable the timeout while the request is queued.

2. The requests object are deleted behind the back of the application, i worked
   around this by using QPointer objects , so at least i know when they are gone.

I see.

For simple applications there isn't any problem, but if you "store" the request objects, you is going to have troubles.

What do you think about this:

1. Implement a new signal, HttpServerRequest::timeoutReached()
2. HttpServer connects timeoutReached() to the QAbstractSocket::close() to maintain backwards compatibility.
3. Complex applications can handle the timeout themself and the request object won't be deleted behind their back.

The question is if we should think about a different approach than directly connecting
request objects to their deleteLater slot, so we can handle these things better.

This is the simplest solution if we don't need special code to be triggered before deletion. The solution can be changed and I don't care, but what special code needs to be triggered before deletion?

[bzeller]

I think this issue is gone with the fd-based thread code. Since in the handler thread the workflow is exactly
as it would be in a single thread application