> From: Shawn McKinney [mailto:[email protected]] > Sendt: 6. januar 2016 16:11 > Til: [email protected] > Emne: Re: Caching checkAccess on session > > > > On Jan 6, 2016, at 8:56 AM, Jan Sindberg <[email protected]> wrote: > > > > n our setup we have lists (or report) with many data items. Some of the > attributes on these items are guarded by permissions that restrict viewing - > an icon for restricted information is shown instead. This is typically > handled in > one thread. In production we will end up with a setup where the ping time > between the server and the LDAP is typically 16 ms. Ignoring processing on > the LDAP that means that at most 30 requests pr. thread can be processed > pr. second. With 2000 permission checks on a list it will take more than a > minute for permission checks alone. > > > > The quick and simple solution is to add a temporary map for caching > responses pr. session / page view. We already have some helper classes > around the fortress api and the session handling, so it is not such a big > issue > to do that. It is more of a surprise because I was focused on the 8K/sec and > forgot that it includes multiple threads and probably is run locally with a > minimum of network latency. > > > > Did I miss a build in mechanism for handling this issue or is there any > > plans > on adding more aggressive caching of permission checks? > > No caching of perms in fortress currently. Worth thinking about adding a > permission cache. I don’t think that would be difficult to do. I suppose I > never went there because that operation is typically so fast it wasn’t worth > the trouble. I can see how it would be useful in a high latency environment. > > There is one thing you can do now, call the accessmgr.sessionpermissions > api, and store that result set in a map locally. That is a typical use case > for > web apps where each page loading requires multiple permission checks. > > Shawn
Thanks. We will do that for now. Down the road we might see users with 200 permissions. We are still looking into this, but it looks like each creation of a session will call the LDAP once for each permission? That means a delay of 6 seconds for each page load if I am correct. I think we will need local caching which can be invalidated by an event or at least through a jmx-console which I think EHCache already supports, and also the fortress cache-api has methods for invalidating cache so that we could implement our own event handling. // Jan
