[
https://issues.apache.org/jira/browse/WICKET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476383
]
Johan Compagner commented on WICKET-201:
----------------------------------------
writing out (idle) sessions is something that should be done by the container.
We shouldn't keep references to the session and alter the session when it is
not in use in a request. (we don't know what the container does with the
sessions (or terracotta))
So the only thing is that we can write pages directly to disk (don't sign them
to the pagemap) for current request if the memory start to get low then the
performance of that will
go down of course, because those are most likely to return again (they are the
active sessions). And when is memory low?? memory could for example be low at
one time (max != current && free < X)
but one GC can free up 30%. Thats a bit difficult to really see at a specific
time..
That every session keeps lingering around is not a problem specific to the
SecondLevelCache. I think that the SLC wil even improve how many live sessions
we can handle
compared to the normal http store. Because there we will have 7 page or page
versions in the session. So the sessions that are still idle are potentially
keeping 7 times more memory then with SLC
Maybe if we know or calculate the average size of session. For the specific
system. Then we can take that into account with the total number of sessions
and then we know what those cost..
And maybe we can somehow use that to decide that we have to overflow. But i
rather left that to the container (idle session to disk)
> refactor storing pages and versions
> -----------------------------------
>
> Key: WICKET-201
> URL: https://issues.apache.org/jira/browse/WICKET-201
> Project: Wicket
> Issue Type: Bug
> Reporter: Eelco Hillenius
> Assigned To: Johan Compagner
> Priority: Critical
> Fix For: 1.3, 2.0
>
>
> See http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html
> for a discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
