Re: https server - memory leaks

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]