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
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
> 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
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]
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
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]
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=7220243&ver=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
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." > > *** >
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]
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." ***
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] > >
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
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]
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
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
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
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
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
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]
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
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
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]
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]
