[erlang-questions] SSL server session cache table issues:

Kenneth Lakin <>
Wed Dec 7 10:13:57 CET 2016

I'm using OTP 19.1.3 on a 32-bit Linux system.

From what I can tell, there's no documented way to control the number of
entries in the server SSL session cache ETS table. (That is, the
server_ssl_otp_session_cache table.) Passing the {reuse_sessions, false}
SSL server option does not prevent new entries in the table. The obvious
(but undocumented) ways to control the number of entries in the server
SSL session cache appear to fail to work.

Is there a way to control the size of the cache, without overriding the
session cache callback with the (undocumented) session_cb ssl
application option? Is my only hope to use the session_cb application
option to switch to a noop session cache manager?

I've software that acts as a TLS server but has no use for the SSL
server session cache. I've a load test that causes one new TLS
connection to be created, used, and (AFAICT, cleanly) destroyed roughly
every half-second. This seems to create one entry in
server_ssl_otp_session_cache roughly every half-second.

This table appears to grow without bound. Conversation from the OTP
18.3-ish days seems to claim that this table has a limit of 1000
entries. My testing indicates that this is untrue; that the table has no
size limit. Additional testing reveals that neither the session_lifetime
nor the session_cache_server_max ssl application options appear to have
any effect. A 20 minute run results in a ~2000 item table, even with
both of these options set to 1.

I'm making use of the (documented!) cb_info ssl server option to provide
an alternate, reliable transport for the TLS data. Might this be
interacting poorly with the session cache cleaning code?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161207/b26d9867/attachment-0001.bin>

More information about the erlang-questions mailing list