<div dir="ltr"><div><div>Hi!<br><br></div>It might be if they have a session callback handling module and do not implement the size function.<br><br></div>Regards Ingela Erlang/OTP team - Ericsson AB<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-08 14:39 GMT+01:00 Kenneth Lakin <span dir="ltr"><<a href="mailto:kennethlakin@gmail.com" target="_blank">kennethlakin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/08/2016 02:09 AM, Ingela Andin wrote:<br>
> I am just saying there is a reason for the [documentation] structure<br>
<span class="">> and knowing about it makes it easier to find things.<br>
<br>
</span>No doubt! In a follow-up email I mentioned that I'd found the ssl_app<br>
documentation, which contained the documentation that I thought didn't<br>
exist. I remain sheepish.<br>
<span class=""><br>
> TLS sessions are not connection specific, so the assumption is that a later<br>
> connection may want to reuse the session, and that by default you want to<br>
> reuse a sessions if possible.<br>
<br>
</span>That makes sense. Thanks for the explanation!<br>
<span class=""><br>
> The max session is not a hard limit, when max is reached<br>
> a process of removing all previous sessions is started.<br>
> It might be a problem if you have a constant high load.<br>
<br>
</span>Actually, the ever-growing session cache table problem seems to be<br>
caused by starting my application with the rebar3 shell. When I invoke<br>
erl directly, the session cache table is regularly purged of old data.<br>
<br>
I'll do some more digging and then maybe report a bug with the rebar3<br>
people. Sorry for the noise!<br>
<br>
<br>
</blockquote></div><br></div></div></div></div></div>