[
https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14548188#comment-14548188
]
Susan Hinrichs commented on TS-3554:
------------------------------------
Agreed on ref-counting the parent session_cache object. That should make
accesses in the callbacks safe. If we do the ref-counting, I don't see the
need for rw-locks. If you have a reference to the old session cache, you
continue to use that to fetch out the reconstituted SSL_SESSION object. When
you are done, you drop the reference, and the old session cache goes away,
taking the serialized forms of the old sessions with it. I assume the openssl
framework takes care of freeing up the SSL_SESSION object when it is done with
it.
We could try to be clever and only reinitialize if the session table
characteristics change. But if the certs change, perhaps that isn't safe
either. Easiest to just always reset I suppose.
> ATS memory leak reloading ssl_multicert.config with many ssl cert configs
> -------------------------------------------------------------------------
>
> Key: TS-3554
> URL: https://issues.apache.org/jira/browse/TS-3554
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Core, SSL
> Reporter: Steven Feltner
> Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
> Attachments: limit_session_cache_alloc.diff, ts-3554-53-2.diff,
> ts-3554-53.diff
>
>
> ATS will consume all available memory on a server with 128GB of RAM.
> @shinrich suspects it may be due to CertLookup table not being freed on a
> config reload.
> Our current process:
> - New cert comes in
> - ssl_multicert.config and remap.config updated
> - traffic_line -x
> This reload could occur as often as every 3 mins with 5000+ certs configured.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
