Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
For remoting could have a sense to make DTO for the sake of Singe Responsibility Principle. 2008/11/26 James Carman [EMAIL PROTECTED]: Not exactly. It might be okay for web projects like this, but if you need to do any remoting, this won't work. Our domain entities have to be serializable. On Wed, Nov 26, 2008 at 11:22 AM, Bruno Cesar Borges [EMAIL PROTECTED] wrote: Now that is a really good advice. :-) -Mensagem original- De: kan [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:19 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- WBR, kan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. *** -- WBR, kan.
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket Session grows too big real fast
LoadableDetachableModel Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Flavius [EMAIL PROTECTED] Sent: Saturday, November 29, 2008 9:40 PM To: users@wicket.apache.org Subject: Re: Wicket Session grows too big real fast 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- WBR, kan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: Wicket Session grows too big real fast
Now that is a really good advice. :-) -Mensagem original- De: kan [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:19 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- WBR, kan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. ***
RES: Wicket Session grows too big real fast
Maybe would be a good idea if Wicket could report memory usage for non-Wicket_Components (and non-standard Java objects, like String and Collections) in memory. I don't know if this could ever be possible. -Mensagem original- De: Ladislav Thon [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:21 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session grows too big real fast
Not exactly. It might be okay for web projects like this, but if you need to do any remoting, this won't work. Our domain entities have to be serializable. On Wed, Nov 26, 2008 at 11:22 AM, Bruno Cesar Borges [EMAIL PROTECTED] wrote: Now that is a really good advice. :-) -Mensagem original- De: kan [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:19 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- WBR, kan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. ***
Re: RES: Wicket Session grows too big real fast
Session/state-fullness is the no. #1 concern for me about Wicket. If you like to keep an eye on certain object trees during runtime, as an alternative to external profiling (which I've always found cumbersome) you can use TopCoders memory usage component: http://software.topcoder.com/catalog/c_component.jsp?comp=7220243ver=2 /Casper Bruno Cesar Borges wrote: Maybe would be a good idea if Wicket could report memory usage for non-Wicket_Components (and non-standard Java objects, like String and Collections) in memory. I don't know if this could ever be possible. -Mensagem original- De: Ladislav Thon [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 26 de novembro de 2008 14:21 Para: users@wicket.apache.org Assunto: Re: Wicket Session grows too big real fast 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) acima identificado(s), podendo conter informações e/ou documentos confidencias/privilegiados e seu sigilo é protegido por lei. Caso você tenha recebido por engano, por favor, informe o remetente e apague-a de seu sistema. Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, cópia ou uso sem expressa autorização do remetente. Opiniões pessoais do remetente não refletem, necessariamente, o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas. Warning: This message was sent for exclusive use of the addressees above identified, possibly containing information and or privileged/confidential documents whose content is protected by law. In case you have mistakenly received it, please notify the sender and delete it from your system. Be noticed that the law forbids the retention, dissemination, distribution, copy or use without express authorization from the sender. Personal opinions of the sender do not necessarily reflect CETIP's point of view, which is only divulged by authorized personnel. *** - 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]
Re: Wicket Session grows too big real fast
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
