HTTP server regression

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP server regression

Martin Nilsson (Coppermist) @ Pike (-) developers forum
Looks like the Protocols.HTTP.Server is broken, though I don't know
how recently as it was a while ago I installed the previous Pike
8.1. It's never the first request that fails, so I'm suspecting
something like keep-alive, though it could be inside the SSL state
(tickets?) things are messed up.

The problem appears to be writes after finished() has been called. As
I said the code used to work in 8.1 and works in 8.0.

Anyone got any obvious idea?

Indexing the NULL value with "output_to".
/usr/local/pike/8.1.13/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike:929:
    Protocols.HTTP.Server.Request("GET" "/test.html")->send_write()
/usr/local/pike/8.1.13/lib/modules/SSL.pmod/File.pike:1315:
    SSL.File(Stdio.File("socket", "85.228.101.175 55103", 777 /* fd=14 */), SSL.ServerConnection(ready))->internal_poll()
-:1: Pike.Backend(0)->`()(3600.0)
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Stephen R. van den Berg
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>Looks like the Protocols.HTTP.Server is broken, though I don't know
>how recently as it was a while ago I installed the previous Pike
>8.1. It's never the first request that fails, so I'm suspecting
>something like keep-alive, though it could be inside the SSL state
>(tickets?) things are messed up.

>The problem appears to be writes after finished() has been called. As
>I said the code used to work in 8.1 and works in 8.0.

>Anyone got any obvious idea?

Most likely something I broke then.  I've been working on integrating
Shuffler in there a lot.
I'll have a look.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Stephen R. van den Berg
Stephen R. van den Berg wrote:
>>The problem appears to be writes after finished() has been called. As

I think I tried to be a bit too agressive regarding cleaning up memory
too soon.  Pushed a fix just now.  Please verify that it works now.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Martin Nilsson (Coppermist) @ Pike (-) developers forum
Well, it's closer...

Bad argument 1 to output_to(). Expected object|function.
Unknown program: output_to(0)
-:1:
    Protocols.HTTP.Server.Request()->OutputBuffer(0 bytes, read=[..272] data=[273..272] free=[273..2048] allocated)->output_to(0)
/usr/local/pike/8.1.14/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike:936:
    Protocols.HTTP.Server.Request("GET" "/")->send_write()
/usr/local/pike/8.1.14/lib/modules/SSL.pmod/File.pike:1315:
    SSL.File(Stdio.File("socket", "85.228.101.175 61597", 777 /* fd=13 */), SSL.ServerConnection(ready))->internal_poll()
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Stephen R. van den Berg
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>Well, it's closer...

>Bad argument 1 to output_to(). Expected object|function.
>Unknown program: output_to(0)

Ok, lingering callbacks.  Squashed.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Martin Nilsson (Coppermist) @ Pike (-) developers forum
>Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Well, it's closer...
>
>>Bad argument 1 to output_to(). Expected object|function.
>>Unknown program: output_to(0)
>
>Ok, lingering callbacks.  Squashed.

Setting the fd to blocking after it has been handed over to the next
request object makes the subsequent request hang. There is still a bug
related to this, but my repeatable testcase now hangs on a page after
193 resources has been loaded. Why did we have to break this?
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Stephen R. van den Berg
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Ok, lingering callbacks.  Squashed.

>Setting the fd to blocking after it has been handed over to the next
>request object makes the subsequent request hang. There is still a bug

It is only set to blocking when it is not being reused and thus
being closed.  Apparently it sometimes fails to close after that.
I'll revisit the code.

>related to this, but my repeatable testcase now hangs on a page after
>193 resources has been loaded. Why did we have to break this?

To avoid race conditions on filedescriptor close.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: HTTP server regression

Martin Nilsson (Coppermist) @ Pike (-) developers forum
>Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>>Ok, lingering callbacks.  Squashed.
>
>>Setting the fd to blocking after it has been handed over to the next
>>request object makes the subsequent request hang. There is still a bug
>
>It is only set to blocking when it is not being reused and thus
>being closed.  Apparently it sometimes fails to close after that.
>I'll revisit the code.
>

My testcase works now. Thanks.
Reply | Threaded
Open this post in threaded view
|

Shuffler and HTTP.Server (Re: HTTP server regression)

Stephen R. van den Berg
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>My testcase works now. Thanks.

You might want to try using the Shufflerised Server.Request mode, simply use:
void httprequest(object request) {
  request->set_mode(Protocols.HTTP.Server.Request.SHUFFLER);
  ...
}

I'm using that in production on a busy server.  Works fine.
Allows me to exceed 100% CPU with one pike instance.

The advantages (done automatically if given the opportunity):
- Less systemcalls (partly due to the use of writev).
- Zero-copy output.
- Optimally filled first packet (reduces number of packets
  on the wire).
- Reduced latency in the initial response packet.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Shuffler and HTTP.Server (Re: HTTP server regression)

Martin Nilsson (Coppermist) @ Pike (-) developers forum
>Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>My testcase works now. Thanks.
>
>You might want to try using the Shufflerised Server.Request mode, simply use:
>void httprequest(object request) {
>  request->set_mode(Protocols.HTTP.Server.Request.SHUFFLER);
>  ...
>}

Actually, there might be a problem still, but I need to make a
consistent test case. It happens if I leave the browser for a while,
so it may be related to Chrome's preconnect plus timeout.