ZnServer + keep alive

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ZnServer + keep alive

Paul DeBruicker
        From reading the Zinc docs here: http://zn.stfx.eu/zn/zinc-http-components-paper.html I can see that ZnClient supports the 'Keep Alive' header.  


Does ZnManagingMultiThreadedServer?  


Seems like it does from the code, assuming the presence of the 'Keep-Alive' header from the client and a HTTP v 1.1 connection, but I'm not sure.  


If so, is there a way to configure the timeout or max # of connections?  I just want to make sure the settings in my nginx proxy match up with Zinc


Thanks

Paul


Reply | Threaded
Open this post in threaded view
|

Re: ZnServer + keep alive

Sven Van Caekenberghe-2
Hi Paul,

On 19 Oct 2013, at 17:31, Paul DeBruicker <[hidden email]> wrote:

> From reading the Zinc docs here: http://zn.stfx.eu/zn/zinc-http-components-paper.html I can see that ZnClient supports the 'Keep Alive' header.  
>
>
> Does ZnManagingMultiThreadedServer?  
>
>
> Seems like it does from the code, assuming the presence of the 'Keep-Alive' header from the client and a HTTP v 1.1 connection, but I'm not sure.  

Yes, both the old(er) HTTP 1.0 Keep-Alive behaviour as well as the current HTTP 1.1 behaviour (which keeps connections open by default) is implemented by both ZnClient and ZnMultiThreadServer and subclasses.

> If so, is there a way to configure the timeout or max # of connections?  I just want to make sure the settings in my nginx proxy match up with Zinc

Currently, the server is lazy in the sense that it keeps connections open forever, or more precisely until they fail. Normally, a server should indeed protect itself by using both a limit on the number of connection that can be active concurrently and a specific timeout for closing kept alive connections.

The max number of connection could be easily added, probably in ZnManagingMultiThreadedServer>>#socketStreamOn: where a 503 could then be returned.

The hook for the other behaviour could be implemented by extending/overriding ZnManagingMultiThreadedServer>>#periodicTasks. The problem is of course that one thread/process would kill the connection of another, which could be in any state.

Of course, putting nginx in front is a nice way to do resource protection in production.

> Thanks
>
> Paul

HTH,

Sven