Re: https server - memory leaks

[Dan Winship <danw gnome org>]

On 12/04/2013 07:32 AM, Bernhard Schuster wrote:
> > In this case, since curl doesn't keep any state between requests, each
> > request would count as a new client. (Whenever a client connects and
> > doesn't pass an existing session ID as part of the TLS handshake, the
> > server will allocate a new session for it.) And since states are
> > currently only cleaned up when they're at least an hour old, your test
> > would never hit the cleanup code, so yes, it would grow linearly.
>
> That behaviour is not really smart, especially in a memory limited
> context with spikes in the number of requests per second it is doomed to
> fail or get killed by the kernel's OOM killer.
>
> I will have a look into it to write some patches making the TTL for
> cache entries configureable (unless somebody/you are doing that already).

No one is working on that.

Making it smarter would be *much* easier than making it configurable; 
the code for the cache is in glib-networking, which means that in order 
to make it configurable from libsoup, you'd have to first add API to 
GTlsServerConnection in glib, then implement that new API in 
GTlsServerConnectionGnutls in glib-networking, and then add API to 
SoupServer to have it call the GTlsServerConnection API...

Whereas, say, just making it always cap the cache at 50 entries rather 
than "50 entries or 1 hour's worth" would only require changes in 
glib-networking.

-- Dan