Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

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://www.ehcache.org/documentation/2.8/faq.html )
"
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