Grouper Users - Open Discussion List

["Black, Carey M." <>]

Michael,

Eventually when the config files are moved into the DB... the separation of 
values ( by component ) will "go away automatically". ( Well that is my 
expectation.)
        However, part of my question was also kind of poking at that idea 
too. As in, are there any config settings that need to remain "by component" 
that is currently done by having different files.

Chris,

Thanks for the details. I am happy that I moved the location in general, but 
it sounds like I should leave them all together in one location.

One follow up question....
RE: " You should delete old files from this folder.  "
        What is the formula to decided "this file is ready to be deleted". ? 
                If the file modify date is..... older than....?
                Or something else?

-- 
Carey Matthew 

-----Original Message-----
From: Gettes, Michael <> 
Sent: Wednesday, July 10, 2019 11:10 AM
To: Chris Hyzer <>
Cc: Black, Carey M. <>;  Mailing 
List <>
Subject: Re: [grouper-users] grouper.cache.properties question.....

And, IMHO, with the new subject caching in 2.4.0 latest ehcache tuning is 
less needed for subject related stuff.  Properly config the subject cache 
with the number of subjects and that’s pretty much it.  I do recommend 
defining a different subject cache for each component for large environments. 
 Maybe there is a better way of doing this going forward instead of different 
subject.properties files for UI, WS, and Loader?

/mrg

> On Jul 10, 2019, at 10:43 AM, Hyzer, Chris <> wrote:
> 
> We need to address this at some point.  You don't need to have different 
> locations since it uses unique file names, right?  You should delete old 
> files from this folder.  There are not any performance tuning suggestions, 
> the defaults are set for large and small envs alike.
> 
> Thanks
> Chris
> 
> -----Original Message-----
> From:  
> <> On Behalf Of Black, Carey M.
> Sent: Tuesday, July 09, 2019 11:34 PM
> To:  Mailing List <>
> Subject: [grouper-users] grouper.cache.properties question.....
> 
> Some time back I found ehcache temp files stacking up and I decided to push 
> them off to a different filesystem to avoid "out of space" issues where 
> they were being spawned.
> When I did that I also ( maybe unjustifiably ) decided that the UI, WS and 
> daemon JVM's should have independent locations for their disk based (L2) 
> cache files.
> 
> I did a bit of "light reading" on the topic and it appears that: ( REF:  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ehcache.org_documentation_2.8_faq.html&d=DwIFAg&c=sJ6xIWYx-zLMB3EPkvcnVg&r=wEQWI9G4vDvpfmhpuO6yww&m=llMZPYIvGHbamwEV5uF1N6rkXRfMbK3Hkqs_lb2CGk0&s=aBaTq9io-7qKYD7d13Pl34klmbNEGxosMiWSoULO_tY&e=
>   )
> "
> Is it thread-safe to modify element values after retrieval from a Cache?
> Remember that a value in a cache element is globally accessible from 
> multiple threads. It is inherently not thread-safe to modify the value. It 
> is safer to retrieve a value, delete the cache element, and then reinsert 
> the value.
> "
> 
> So.. my questions.
> 
> 1) Should the separate JVM's ( UI/WS/daemon, all on the same host ) use 
> separate cache file locations? ( Is it reasonable to be concerned about 
> this detail? )
> 2) Are there any performance tuning suggestions about grouper's use of 
> ehcache?  ( other than file store location(s). )
>       Maybe things like....
>               If you have "X" in your grouper then you should likely set 
> "yyy.maxElementsInMemory" to 30% of "X".
>               Don't mess with the defaults, they scale well and you might 
> break something if you go mucking about in there...
> 
> :)
> 
> -- 
> Carey Matthew