Re: [uportal-dev] LAYOUT_CACHE: Is this an interesting enhancement?

[Eric Dalquist]

This sounds great, just the sort of thing I was hoping for with the better caching backend.

A few questions:
1. How are the cache entries keyed?

3. Does this also move the DLM fragment cache into a managed cache as well?

-Eric

Drew Wills wrote:

2. Does this change the cached entry invalidation logic at all from the existing code?

Hey folks,



This situation means that:

   - There's no way to manage in-memory layout data administratively

With this enhancement, you'd be able to:




I'm attaching a .patch that shows the delta.



drew wills

I'm working at JHU, and we've put together an enhancement to DLM: the ability to store users' layouts in a standard, portal managed cache. Currently users' layouts are stored (at least in DLM) as a member variable on each user's LayoutManager instance. - User layouts never change until (1) the user makes a manual change, or (2) the user logs in again - specify that user layouts should expire and be rebuilt, say, 15 min after creation or after 10 min of "idle" time (i.e. not used for 10 min) - specify that no more than, say, 500 layouts should be held in memory at one time - use JMX to "clear" (drop) all the layouts in a running instance of uPortal - write Java tools that intelligently invalidate individual layouts (or all layouts) when certain portal events happen The changes are relatively small & encapsulated, so they're unlikely to "break" existing features or even custom Java tech that integrates with DLM. Please share thoughts on whether this enhancement is desirable or even acceptable. If there's interest, I'll create the JIRA etc.

smime.p7s
Description: S/MIME Cryptographic Signature