Good point, thanks. Any idea on how to get this working with clustering?
The question is how to schedule expiration of a PageMap without keeping
a global (weak) reference to it.
But anyway, your objections are against my custom implementation only,
not the changes to SecondLevelCachePageMap. I'd be super happy if these
could make their way into core.
On 08/09/2010 05:00 PM, Johan Compagner wrote:
I am against that patch.
You keep pagemaps in memory in the applicaiton context!
Those are session stuff stored in the HttpSession. You shouldnt keep
reference to those stuff.
This can break all kind of things (for example clustering)
If you want something like that, then it is fine if we need to change
something so that you can overwrite some stuff so that you can do what
you want without patching wicket.
But i dont want this to be default in wicket.
On Mon, Aug 9, 2010 at 16:43, Stefan Fussenegger<[email protected]> wrote:
Hi all,
It's been more than 2 month since I've created WICKET-2889 and submitted a
patch to fix it. As nobody commented yet, I thought I should mention it
here.
The attached patch reduced required heap space for stateful pages by 2/3
(depends on configuration though,>100M for my application running with a
total heap of 768M) without any noticeable impact on performance. I'm using
a custom PageMap that requires a few trivial changes in
SecondLevelCachePageMap (visibility and a hook called
onAfterLastPageSet(..)). I doubt that there's any reason not to apply it for
1.4.10. Whether to include the new class
(ExpiringSecondLevelCacheSessionStore) is optional, but I'd consider it a
valuable addition to core.
Please see https://issues.apache.org/jira/browse/WICKET-2889
<https://issues.apache.org/jira/browse/WICKET-2361>
<https://issues.apache.org/jira/browse/WICKET-2361> for details.
Cheers, Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
