good point Mav. This is a long discussion around the ticket registry design and I think I created a Jira a long time ago gor this. It might be enough to expose the ticket timestamp in an own attribute of the registry so a deserialization of all tickets in the cleaner wouldn't be needed. Disabling SLO is not an option in our case, as you do not know when a logout occurs and users expect to be logged out from all services on SLO.
Sent while mobile. Am 18.12.2014 um 16:12 schrieb Marvin Addison <[email protected]>: >> When I got a heap dump I was shocked to see that there were tickets in there >> which took close to 10Mb of memory (deserialized). After investigation this >> was pretty much all allocated in the 'services' map that is stored in the >> TGT. > > This is a known issue and a great example of why we need to tighten up the > storage model in future versions of CAS. We hold on to way more data than is > needed to track accessed services (needed for logout). That said, despite > improvements and optimizations, it's not unreasonable to expect problems from > an SSO session that tracks service sessions for 90 days. We might want to > expose a configuration knob to turn off session tracking since the only case > for that is SLO, which is meaningless over a span that long. It seems like > you pretty much came to a similar conclusion on your own. > > You might reframe your problem as a design suggestion and discuss further on > cas-dev. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
