Thanks for the advice. Unfortunately we cannot do this here, because the
ListViews contain Link components for user interaction.
Actually I was wondering why it is necessary to keep all of the list
items in the session when the next time the page is rendered the list
items are regenerated according to the underlying model of the ListView.
The first thing I tried was removing all list items after the page
was rendered - which I am not allowed. Then, after I studied the wicket
sources, I tried a weird hack and wrote a replacement for ListView which
added the list items as "auto components". This worked, but
unfortunately the links did not work anymore, because there were no link
components on the page left ...
Ralf.
Igor Vaynberg wrote:
if you are planning on displaying 1000 rows per page, which is quiet
uncommon for webapps, you should produce output as raw html instead of
using listview and adding components inside.
-igor
On Thu, Nov 20, 2008 at 7:15 AM, Ralf Siemon <[EMAIL PROTECTED]> wrote:
Hi,
we have recently launched our new Wicket-based website, and now we are
experiencing that the memory consumption of the website is very high, so
that it crashes the site regularly.
When profiling the application server, we found out that there are HTTP
sessions that consume up to 2 MB of memory, mostly because there are very
large ListViews with up to 1000 entries, where each entry consumes about 2
KB.
Our preliminary solution is to limit the size of those ListViews to a
maximum of 50 entries, but even in those cases the session size is still at
about 200 KB, which seems quite large to us.
I know that there have already been some discussions about memory
consumption in Wicket due to the fact that the whole Page object of the last
visited page is stored in the session; but what I'd like to know is: Have
you experienced session sizes in a comparable magnitude, or are we doing
something wrong? Or is this something we have to live with when using
Wicket?
We are using Wicket 1.3.5.
Thanks,
Ralf.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
