A time or LRU algorithm is not really a good thing here even when I use a page just once a day, I do not want to have it initialzed on the fly. You might run into problems with holding you SLA.

In my opinion Tapestry is designed to Cache the pages. If it cannot do so - it must throw an error and should not start to hide problems.

On comparison:
Would you expect your EntityManager configuration to be soft referenced and be thrown away on memory presaure - or if the entity manager throws away entitiy configuration not used for more than one day and you are wondering why this stuff takes so long to query it?
I see a tapestry page quite similiar to this example.

Robert



Am 18.03.2015 um 00:26 schrieb Howard Lewis Ship:
Possibly we need something more advanced; our own reference type that can
react to memory pressure by discarding pages that haven't been used in
configurable amount of time.

Or perhaps we could just assume that any page that has been used once need
to be used in the future and get rid of the SoftReference entirely (or
otherwise janitorize it in some way).

On Tue, Mar 17, 2015 at 1:24 AM, Robert Schmelzer <rob...@schmelzer.cc>
wrote:

Hello,

I recently came accross the implementation of PageSourceImpl where
PageImpl instances are softly refereneced into the pageCache:

private final Map<CachedPageKey, SoftReference<Page>> pageCache =
CollectionFactory.newConcurrentMap();

This implementation caused troubles, when you bring your system into
memory preassure. The JVM will start to throw away the PageImpl to free up
memory - but during request processing he needs the PageImpl again and
starts creating it again. So basically you end up loosing your pageCache at
all and start creating the PageImpl instances on every request, which take
way to much time and takes load onto the CPU. So basically you are hiding a
memory problem by making the system slow and raise CPU load.

I would suggest to use "normal" references for the PageCache or at least
only do SoftReferences only when not in production mode. Otherwise we are
going to cover memory problems for too long.

What do you think about that?

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to