You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by jhp <ju...@gmail.com> on 2008/11/26 10:02:58 UTC
Wicket Session grows too big real fast
Hi,
I have a serious problem with our application. It uses
wicket+guice+hibernate technologies. The problem basically is that the
application was developed with very little attention to the possible session
size, and it is biting us now.
The are several domain classes and the dependecies are not the simplest
possible. For example frontpage shows a listing of objects, and for each
object it shows a name and a link etc.
For the listing I have used LoadableDetachableModel, the model is passed to
a Panel, that then uses this type of structure:
ListView recommendationListView = new ListView("recommendationListView",
recommendationListModel) {
@Override
protected void populateItem(ListItem item) {
final Recommendation recommendation = (Recommendation)
item.getModelObject();
ExternalLink link = new
ExternalLink("recommendationLink","/recommendation/id/" +
recommendation.getId());
item.add(link);
And this type of structure is used all over the application. I thought that
this was OK, but now I am not sure. When I run the code in production
environment and test it with jmeter script, i can see that the the memory
tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
SESSIONS.ser file that tomcat generates, I can see there are lots of domain
classes serialized to the session. And as domain classes have other domain
classes as collections and they might have still more (altough I use
FetchType= Lazy whereever I can), it's easy to see why sessions start to
take too much memory and eventually java.lang.OutOfMemoryError: Java heap
space appears.
Are there any possible things that I could try? Or do I have to go throug
the code and try to change everything to LoadableDetachableModel, which will
be very tedious. Any help to the problem, or more accurate ways to pinpoint
the problem, would be greatly appreceated.
BR,
Jukka
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by jhp <ju...@gmail.com>.
In that place, it compiles without it, but I have another class that has
something like this:
final Recommendation currentRecommendation = (Recommendation)
recommendationModel.getObject();
.
.
.
add(new Label("usersChoice", getUsersChoiceString(name.getFirstname())) {
@Override
public boolean isVisible() {
return currentRecommendation.getSupplier() != null;
}
});
And it doesn't compile without final. so does that mena that this is teh
palce which forces the recommendation object to be stored in the session? I
have to admit that it didn't occur to me.
Jukka
Johan Compagner wrote:
>
> if you make this:
>
> final Recommendation recommendation = (Recommendation)
> item.getModelObject();
>
> not final does it compile?
>
> If it doesnt then you have a leak
>
> johan
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Martijn Dashorst <ma...@gmail.com>.
Yes, since the anon-inner class introduces a link between the two.
modify the isVisible() to:
return ((Recommendation)recommendationModel.getObject()).getSupplier() == null;
or rather, implement a method "Recommendation
getCurrentRecommendation() { return
((Recommendation)recommendationModel.getObject());}
and use that instead.
Martijn
On Wed, Nov 26, 2008 at 10:52 AM, jhp <ju...@gmail.com> wrote:
>
> In that place, it compiles without it, but I have another class that has
> something like this:
> final Recommendation currentRecommendation = (Recommendation)
> recommendationModel.getObject();
> .
> .
> .
> add(new Label("usersChoice", getUsersChoiceString(name.getFirstname())) {
> @Override
> public boolean isVisible() {
> return currentRecommendation.getSupplier() != null;
> }
> });
>
> And it doesn't compile without final. so does that mean that this is the
> place which forces the recommendation object to be stored in the session? If
> so, I have to admit that I missed it entirely.
>
> Jukka
>
>
> Johan Compagner wrote:
>>
>> if you make this:
>>
>> final Recommendation recommendation = (Recommendation)
>> item.getModelObject();
>>
>> not final does it compile?
>>
>> If it doesnt then you have a leak
>>
>> johan
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697806.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by jhp <ju...@gmail.com>.
In that place, it compiles without it, but I have another class that has
something like this:
final Recommendation currentRecommendation = (Recommendation)
recommendationModel.getObject();
.
.
.
add(new Label("usersChoice", getUsersChoiceString(name.getFirstname())) {
@Override
public boolean isVisible() {
return currentRecommendation.getSupplier() != null;
}
});
And it doesn't compile without final. so does that mean that this is the
place which forces the recommendation object to be stored in the session? If
so, I have to admit that I missed it entirely.
Jukka
Johan Compagner wrote:
>
> if you make this:
>
> final Recommendation recommendation = (Recommendation)
> item.getModelObject();
>
> not final does it compile?
>
> If it doesnt then you have a leak
>
> johan
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Johan Compagner <jc...@gmail.com>.
if you make this:
final Recommendation recommendation = (Recommendation)
item.getModelObject();
not final does it compile?
If it doesnt then you have a leak
johan
On Wed, Nov 26, 2008 at 10:02 AM, jhp <ju...@gmail.com> wrote:
>
> Hi,
>
> I have a serious problem with our application. It uses
> wicket+guice+hibernate technologies. The problem basically is that the
> application was developed with very little attention to the possible
> session
> size, and it is biting us now.
>
> The are several domain classes and the dependecies are not the simplest
> possible. For example frontpage shows a listing of objects, and for each
> object it shows a name and a link etc.
> For the listing I have used LoadableDetachableModel, the model is passed to
> a Panel, that then uses this type of structure:
> ListView recommendationListView = new ListView("recommendationListView",
> recommendationListModel) {
> @Override
> protected void populateItem(ListItem item) {
> final Recommendation recommendation = (Recommendation)
> item.getModelObject();
> ExternalLink link = new
> ExternalLink("recommendationLink","/recommendation/id/" +
> recommendation.getId());
> item.add(link);
>
> And this type of structure is used all over the application. I thought that
> this was OK, but now I am not sure. When I run the code in production
> environment and test it with jmeter script, i can see that the the memory
> tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
> SESSIONS.ser file that tomcat generates, I can see there are lots of domain
> classes serialized to the session. And as domain classes have other domain
> classes as collections and they might have still more (altough I use
> FetchType= Lazy whereever I can), it's easy to see why sessions start to
> take too much memory and eventually java.lang.OutOfMemoryError: Java heap
> space appears.
>
> Are there any possible things that I could try? Or do I have to go throug
> the code and try to change everything to LoadableDetachableModel, which
> will
> be very tedious. Any help to the problem, or more accurate ways to pinpoint
> the problem, would be greatly appreceated.
>
> BR,
> Jukka
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket Session grows too big real fast
Posted by kan <ka...@gmail.com>.
I am not sure if it always applicable, but usually I do not do
"implements Serializable" for domain objects (it works well with
Hibernated POJOs). In this case the Wicket cannot serialize a
component, and if it was a link to any such object - wicket just
reports about it into log, so you can see right away which component
has tried to "steal" a reference to an object (like in your situation
with inner class).
2008/11/26 jhp <ju...@gmail.com>:
>
> Removing references pointing to previous pages solved a lot, very good point.
> Also making sure that individual domain objects don't get stored to session
> makes a difference. I have still a lot of code to go through to make sure
> that all unnecessary references don't get stored to session, but making a
> few changes in the most important pages makes already a big difference.
>
> I noticed that this is a problem that others have experienced too. I guess
> it is pretty easy unintentionally stuff the session with domain objects ,and
> if using modern day persistence framework, those domain objects can be quite
> large if they have collections etc.
>
> I think there is a need for small document outlining the common pitfalls and
> remedies for them. I haven't seen such. Wicket reference of course tells
> about LoadableDetachableModel, but this thread has info that I haven't found
> anywhere else. I might try compose such a document, if I just have the time
> and energy in the near future.
>
> Thanks to Martijn, Johan and John for your responses!
>
> BR,
> Jukka
>
>
>
>
> Martijn Dashorst wrote:
>>
>> With Wicket 1.3 only one page should be stored in session. You should
>> check if you don't keep references between pages -> that would result
>> in 1+N pages (with N being the number of pages you reference in your
>> page).
>>
>> Other than that: using LDM's and DataView/DataProvider instead of
>> ListView will help considerably.
>>
>> Martijn
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
WBR, kan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Ladislav Thon <la...@gmail.com>.
Agree. I was almost shocked :-) by Martijn's e-mail about keeping references
between pages. I believed it is a "standard" practice to keep reference to
previous page for the purpose of "cancelling", and of course do it all the
time. It seems very natural to me. O-oops.
LT
2008/11/26 Piller Sébastien <pi...@hmcrecord.ch>
> I vote for such a document, too. I am now trying to reduce my session size
> too, and if I could find some hints somewhere (ie, "be extremly carefull
> with anonymous subclasses", etc) it may be a big plus.
>
> jhp a écrit :
>
>> Removing references pointing to previous pages solved a lot, very good
>> point.
>> Also making sure that individual domain objects don't get stored to
>> session
>> makes a difference. I have still a lot of code to go through to make sure
>> that all unnecessary references don't get stored to session, but making a
>> few changes in the most important pages makes already a big difference.
>>
>> I noticed that this is a problem that others have experienced too. I guess
>> it is pretty easy unintentionally stuff the session with domain objects
>> ,and
>> if using modern day persistence framework, those domain objects can be
>> quite
>> large if they have collections etc.
>>
>> I think there is a need for small document outlining the common pitfalls
>> and
>> remedies for them. I haven't seen such. Wicket reference of course tells
>> about LoadableDetachableModel, but this thread has info that I haven't
>> found
>> anywhere else. I might try compose such a document, if I just have the
>> time
>> and energy in the near future.
>>
>> Thanks to Martijn, Johan and John for your responses!
>>
>> BR,
>> Jukka
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket Session grows too big real fast
Posted by Piller Sébastien <pi...@hmcrecord.ch>.
I vote for such a document, too. I am now trying to reduce my session
size too, and if I could find some hints somewhere (ie, "be extremly
carefull with anonymous subclasses", etc) it may be a big plus.
jhp a écrit :
> Removing references pointing to previous pages solved a lot, very good point.
> Also making sure that individual domain objects don't get stored to session
> makes a difference. I have still a lot of code to go through to make sure
> that all unnecessary references don't get stored to session, but making a
> few changes in the most important pages makes already a big difference.
>
> I noticed that this is a problem that others have experienced too. I guess
> it is pretty easy unintentionally stuff the session with domain objects ,and
> if using modern day persistence framework, those domain objects can be quite
> large if they have collections etc.
>
> I think there is a need for small document outlining the common pitfalls and
> remedies for them. I haven't seen such. Wicket reference of course tells
> about LoadableDetachableModel, but this thread has info that I haven't found
> anywhere else. I might try compose such a document, if I just have the time
> and energy in the near future.
>
> Thanks to Martijn, Johan and John for your responses!
>
> BR,
> Jukka
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by jhp <ju...@gmail.com>.
Removing references pointing to previous pages solved a lot, very good point.
Also making sure that individual domain objects don't get stored to session
makes a difference. I have still a lot of code to go through to make sure
that all unnecessary references don't get stored to session, but making a
few changes in the most important pages makes already a big difference.
I noticed that this is a problem that others have experienced too. I guess
it is pretty easy unintentionally stuff the session with domain objects ,and
if using modern day persistence framework, those domain objects can be quite
large if they have collections etc.
I think there is a need for small document outlining the common pitfalls and
remedies for them. I haven't seen such. Wicket reference of course tells
about LoadableDetachableModel, but this thread has info that I haven't found
anywhere else. I might try compose such a document, if I just have the time
and energy in the near future.
Thanks to Martijn, Johan and John for your responses!
BR,
Jukka
Martijn Dashorst wrote:
>
> With Wicket 1.3 only one page should be stored in session. You should
> check if you don't keep references between pages -> that would result
> in 1+N pages (with N being the number of pages you reference in your
> page).
>
> Other than that: using LDM's and DataView/DataProvider instead of
> ListView will help considerably.
>
> Martijn
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20702093.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Alex Objelean <al...@isdc.ro>.
LDM is a LoadableDetachableModel
Flavius wrote:
>
>
>
> Martijn Dashorst wrote:
>>
>> With Wicket 1.3 only one page should be stored in session. You should
>> check if you don't keep references between pages -> that would result
>> in 1+N pages (with N being the number of pages you reference in your
>> page).
>>
>> Other than that: using LDM's and DataView/DataProvider instead of
>> ListView will help considerably.
>>
>> Martijn
>>
>
> May I ask what LDM is? Is that Lightweight Data Model?
>
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20802687.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Flavius <na...@silverlion.com>.
Martijn Dashorst wrote:
>
> With Wicket 1.3 only one page should be stored in session. You should
> check if you don't keep references between pages -> that would result
> in 1+N pages (with N being the number of pages you reference in your
> page).
>
> Other than that: using LDM's and DataView/DataProvider instead of
> ListView will help considerably.
>
> Martijn
>
May I ask what LDM is? Is that Lightweight Data Model?
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20754276.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Eelco Hillenius <ee...@gmail.com>.
> With Wicket 1.3 only one page should be stored in session. You should
> check if you don't keep references between pages -> that would result
> in 1+N pages (with N being the number of pages you reference in your
> page).
That's optimized though, so shouldn't typically be a problem. See the
custom read/ write serialization methods in Component and Page and
PageSerializer in AbstractPageStore.
I think the main concern you should have is with serialized domain
objects, especially if you use ORMs like Hibernate and such, since
that makes it all too easy to just read in half of your database with
very little programming effort.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by jWeekend <jw...@cabouge.com>.
Martijn,
If you can put a little bit more meat on this, or give a stronger hint where
to start looking, I'd like to add something to the
http://cwiki.apache.org/confluence/display/WICKET/Wicket+Session+Size Wicket
Session Size Wiki page . See the "Keeping a reference to the previous page"
section.
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
PS I sent email on another matter to your personal email address.
Martijn Dashorst wrote:
>
> iirc there a method to get the previous page from the page map without
> keeping a reference. Search the list for such a thing. Something with
> PageId or such.
>
> Martijn
>
> /me curses memory leakage in himself
>
> On Wed, Nov 26, 2008 at 10:35 AM, jhp <ju...@gmail.com> wrote:
>>
>> Well, yes references to pages seems to be given as constructor arguments
>> to
>> several pages. The idea is that if 'Cancel' is clicked, application goes
>> back to previous page. The possibility to go back more than one page is
>> not
>> necessary. Is the correct way to implement cancle with some javascript
>> that
>> does something like user clicking previous page?
>>
>> Jukka
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> With Wicket 1.3 only one page should be stored in session. You should
>>> check if you don't keep references between pages -> that would result
>>> in 1+N pages (with N being the number of pages you reference in your
>>> page).
>>>
>>> Other than that: using LDM's and DataView/DataProvider instead of
>>> ListView will help considerably.
>>>
>>> Martijn
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20710054.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Martijn Dashorst <ma...@gmail.com>.
iirc there a method to get the previous page from the page map without
keeping a reference. Search the list for such a thing. Something with
PageId or such.
Martijn
/me curses memory leakage in himself
On Wed, Nov 26, 2008 at 10:35 AM, jhp <ju...@gmail.com> wrote:
>
> Well, yes references to pages seems to be given as constructor arguments to
> several pages. The idea is that if 'Cancel' is clicked, application goes
> back to previous page. The possibility to go back more than one page is not
> necessary. Is the correct way to implement cancle with some javascript that
> does something like user clicking previous page?
>
> Jukka
>
>
> Martijn Dashorst wrote:
>>
>> With Wicket 1.3 only one page should be stored in session. You should
>> check if you don't keep references between pages -> that would result
>> in 1+N pages (with N being the number of pages you reference in your
>> page).
>>
>> Other than that: using LDM's and DataView/DataProvider instead of
>> ListView will help considerably.
>>
>> Martijn
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by John Krasnay <jo...@krasnay.ca>.
If the previous page is bookmarkable you don't need to keep a reference
to the page instance; instead, just re-create the page parameters and
call setResponsePage(pageClass, parameters) when the user clicks Cancel.
jk
On Wed, Nov 26, 2008 at 01:35:11AM -0800, jhp wrote:
>
> Well, yes references to pages seems to be given as constructor arguments to
> several pages. The idea is that if 'Cancel' is clicked, application goes
> back to previous page. The possibility to go back more than one page is not
> necessary. Is the correct way to implement cancle with some javascript that
> does something like user clicking previous page?
>
> Jukka
>
>
> Martijn Dashorst wrote:
> >
> > With Wicket 1.3 only one page should be stored in session. You should
> > check if you don't keep references between pages -> that would result
> > in 1+N pages (with N being the number of pages you reference in your
> > page).
> >
> > Other than that: using LDM's and DataView/DataProvider instead of
> > ListView will help considerably.
> >
> > Martijn
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by jhp <ju...@gmail.com>.
Well, yes references to pages seems to be given as constructor arguments to
several pages. The idea is that if 'Cancel' is clicked, application goes
back to previous page. The possibility to go back more than one page is not
necessary. Is the correct way to implement cancle with some javascript that
does something like user clicking previous page?
Jukka
Martijn Dashorst wrote:
>
> With Wicket 1.3 only one page should be stored in session. You should
> check if you don't keep references between pages -> that would result
> in 1+N pages (with N being the number of pages you reference in your
> page).
>
> Other than that: using LDM's and DataView/DataProvider instead of
> ListView will help considerably.
>
> Martijn
>
>
--
View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697523.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket Session grows too big real fast
Posted by Martijn Dashorst <ma...@gmail.com>.
With Wicket 1.3 only one page should be stored in session. You should
check if you don't keep references between pages -> that would result
in 1+N pages (with N being the number of pages you reference in your
page).
Other than that: using LDM's and DataView/DataProvider instead of
ListView will help considerably.
Martijn
On Wed, Nov 26, 2008 at 10:02 AM, jhp <ju...@gmail.com> wrote:
>
> Hi,
>
> I have a serious problem with our application. It uses
> wicket+guice+hibernate technologies. The problem basically is that the
> application was developed with very little attention to the possible session
> size, and it is biting us now.
>
> The are several domain classes and the dependecies are not the simplest
> possible. For example frontpage shows a listing of objects, and for each
> object it shows a name and a link etc.
> For the listing I have used LoadableDetachableModel, the model is passed to
> a Panel, that then uses this type of structure:
> ListView recommendationListView = new ListView("recommendationListView",
> recommendationListModel) {
> @Override
> protected void populateItem(ListItem item) {
> final Recommendation recommendation = (Recommendation)
> item.getModelObject();
> ExternalLink link = new
> ExternalLink("recommendationLink","/recommendation/id/" +
> recommendation.getId());
> item.add(link);
>
> And this type of structure is used all over the application. I thought that
> this was OK, but now I am not sure. When I run the code in production
> environment and test it with jmeter script, i can see that the the memory
> tomcat reserves grows rapidly. When I shutdown tomcat and investigate the
> SESSIONS.ser file that tomcat generates, I can see there are lots of domain
> classes serialized to the session. And as domain classes have other domain
> classes as collections and they might have still more (altough I use
> FetchType= Lazy whereever I can), it's easy to see why sessions start to
> take too much memory and eventually java.lang.OutOfMemoryError: Java heap
> space appears.
>
> Are there any possible things that I could try? Or do I have to go throug
> the code and try to change everything to LoadableDetachableModel, which will
> be very tedious. Any help to the problem, or more accurate ways to pinpoint
> the problem, would be greatly appreceated.
>
> BR,
> Jukka
>
>
>
> --
> View this message in context: http://www.nabble.com/Wicket-Session-grows-too-big-real-fast-tp20697077p20697077.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org