We are still experiencing a problem with the expiration of TGT's Ehache. The “timeToKillInSeconds” value seems to have no effect on removing the TGT from Ehcache temp folder. The TGT entries are not deleted until the “maxTimeToLiveInSeconds” is reached. The attached log illustrates that CAS detects the TGT is expired and the TGT is removed however these same messages are written again every 2 minutes. We observe that the file still exists in the temp ehcache folder and does not get deleted until the “maxTimeToLiveInSeconds” is reached.
We are currently using 5.2.2-SNAPSHOT within a two server HA environment
cas.ticket.tgt.maxTimeToLiveInSeconds=28800
cas.ticket.tgt.timeToKillInSeconds=240
cas.ticket.registry.ehcache.replicateUpdatesViaCopy=true
cas.ticket.registry.ehcache.cacheManagerName=ticketRegistryCacheManager
cas.ticket.registry.ehcache.replicatePuts=true
cas.ticket.registry.ehcache.replicateUpdates=true
cas.ticket.registry.ehcache.memoryStoreEvictionPolicy=LRU
cas.ticket.registry.ehcache.configLocation=file:///opt/login-test/config/ehcache-replicated.xml
cas.ticket.registry.ehcache.maximumBatchSize=100
cas.ticket.registry.ehcache.shared=true
cas.ticket.registry.ehcache.replicationInterval=10000
cas.ticket.registry.ehcache.cacheTimeToLive=240
cas.ticket.registry.ehcache.diskExpiryThreadIntervalSeconds=0
cas.ticket.registry.ehcache.replicateRemovals=true
cas.ticket.registry.ehcache.maxChunkSize=5000000
cas.ticket.registry.ehcache.maxElementsOnDisk=0
cas.ticket.registry.ehcache.maxElementsInCache=0
cas.ticket.registry.ehcache.maxElementsInMemory=10000
cas.ticket.registry.ehcache.eternal=false
cas.ticket.registry.ehcache.loaderAsync=true
cas.ticket.registry.ehcache.replicatePutsViaCopy=true
cas.ticket.registry.ehcache.cacheTimeToIdle=240
cas.ticket.registry.ehcache.persistence=LOCALTEMPSWAP
cas.ticket.registry.ehcache.synchronousWrites=false
Any insight or thoughts would be great!
-Gary
.
-- Ray Bon Programmer analyst Development Services, University Systems 2507218831 | CLE 019 | rb...@uvic.ca
Hi Ray,
Thank you for looking at this problem.
After the TGT times out, CAS continually tries to perform a purge of the TGT and writes out the following message over and over until it reaches the maximum lifetime. This is a problem just due to the volume of messages that are being generated for each user.
[INFO] 2018-02-19 08:38:52,239 org.apereo.cas.logout.DefaultLogoutManager performLogout - Performing logout operations for [TGT-**************************2JSFkHAz39-Poi85P7wTMGVm61SI0R0iSZMDzDU-2hxwuK4-login-test.fortlewis.edu]
[INFO] 2018-02-19 08:40:52,276 org.apereo.cas.logout.DefaultLogoutManager performLogout - Performing logout operations for [TGT-**************************2JSFkHAz39-Poi85P7wTMGVm61SI0R0iSZMDzDU-2hxwuK4-login-test.fortlewis.edu]
[INFO] 2018-02-19 08:42:52,306 org.apereo.cas.logout.DefaultLogoutManager performLogout - Performing logout operations for [TGT-**************************2JSFkHAz39-Poi85P7wTMGVm61SI0R0iSZMDzDU-2hxwuK4-login-test.fortlewis.edu]
[INFO] 2018-02-19 08:44:52,329 org.apereo.cas.logout.DefaultLogoutManager performLogout - Performing logout operations for [TGT-**************************2JSFkHAz39-Poi85P7wTMGVm61SI0R0iSZMDzDU-2hxwuK4-login-test.fortlewis.edu]
In our current production environment a CAS ticket is initially good for 4 hours but if the user continues to interact with CAS enabled applications that CAS ticket’s lifetime is extendable up to 8 hours. We are currently running 4.0.3 in production and I have included a snippet from ticketExpirationPolicies.xml. Does the same process I’ve described work in CAS 5.2.2?
<!-- TicketGrantingTicketExpirationPolicy: Default as of 3.5 -->
<!-- Provides both idle and hard timeouts, for instance 2 hour sliding window with an 8 hour max lifetime -->
<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy"
p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}"
p:timeToKillInSeconds="${tgt.timeToKillInSeconds:14400}"/>
We do have “Remember Me” turned off.
-Gary
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1518824432.1763.55.camel%40uvic.ca.
I did some more looking into how “EhCacheTicketRegistry.java” class is interfacing with Ehcache and not sure how this can be working for “cas.ticket.tgt.timeToKillInSeconds”.
CAS gets an Element from Ehache within the getTicket() function. CAS then determines if it is expired. When CAS determines that it went past the idle time it performs a ehcache.remove(). The problem is that Ehcache always returns a false when it tries to remove it. The TGT is not being removed. I examined the properties of the Element to determine why Ehcache would not remove it and the Last Access date was updated to contain the time that the getTicket() function was executed. Ehcache must now think that it is active and not expired. So basically I think when CAS is trying to remove a ticket that has timed out, Ehcache won’t do it because the last access date was updated during this process.
The cleaner however does remove the TGT when it hits “maxTimeToLiveInSeconds”.
I tried to get around this problem by turning off the cleaner and setting “DiskExpiryThreadIntervalSeconds” to 120 seconds. That way Ehcache would remove it however the Ehcache Expiry Thread however never runs.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1519068189.1765.26.camel%40uvic.ca.