Tested integration in Studio and the Debian installer, looks good, merging.
On 4/9/19 3:17 AM, Emmanuel Lécharny wrote: > Many thanks, Stefan ! > > AFAICT, all the changes you've made make sense, and we can decide to > tune that later on if needed ! > > On 08/04/2019 22:32, Stefan Seelmann wrote: >> Hi all, >> >> with the update to Ehcache v3 some things broke: >> * It just doesn't work with Java 11 and OSGi (Studio) >> * The "group" cache configuration is wrong, it expires after 1200 >> seconds but it must not expire as the logic relies on it >> * Cache size configured in partition configuration is no longer applied >> >> I did a first attempt to replace it with JCache and Caffeine but failed >> with other OSGi related issues. >> >> Finally I replaced ehcache with Caffeine only and it seems to work. I >> still have to test that it also works in Studio and verify the >> installers. Reviews and comments welcomed [1]. >> >> This includes some noteworthy changes: >> >> 1) Removal of the CacheService and config file: While Caffeine supports >> some kind of configuration (so called specs) that can be read from a >> config file I think it doesn't make sense to continue to use it. Most >> cache sizes are configurable via the server config, The TTLs and other >> cache characteristics can be configured at the places where the cache is >> needed. >> >> 2) Group cache: With ehcache v2 the group cache was configured to not >> evict an entries, but overflow to disk in case there are too many groups >> to avoid OOM. Caffeine does not support that (there are some workarounds >> though). For simplicity I changed the group cache to just use an >> ConcurrentHashMap. If we want to scale to 10000s of groups this has to >> be rewritten anyway. >> >> 3) Krb and ChangePwd replay cache: This is used to protect against >> replay attacks. With ehcache v2 those caches were also configured to >> overflow to disk to limit memory usage. I changed it to an unbounded >> cache with 5 minutes TTL, I don't see a danger of running OOM because >> only valid authentication attemps are stored in that cache. >> >> 4) DN cache: This is a single global cache used by DnFactory. The cache >> is now created in directly within DnFactory, the cache size it >> determined by the largest cache size configured in any of the partitions. >> >> 5) Partition specific caches (entryDn, piar, alias, and entry caches): >> Some of those were shared between partitions, but cache size was >> updated. Now each partition has its own dedicated set of caches with the >> individually configured cache size. >> >> Kind Regards, >> Stefan >> >> [1] https://github.com/apache/directory-server/pull/14 >> >> >> >>
