Session size vs detached models

[Daniel Stoch]

Hi,

In Wicket 1.4 the last page reference is hold in a session (is it in 6.x
also?). So after a request has been processed all components and models
should be detached, so this last page reference should not hold transient
LDM values. Is it true?

When we are using DebugBar with SessionSizeDebugPanel, it displays session
size and totalSize (by SessionTotalSizeModel). Does this totalSize includes
size of object loaded by LDM or it counts all components and models size in
detached state?

--
Daniel

Re: Session size vs detached models

[Martin Grigorov]

Hi,

On Fri, Feb 14, 2014 at 3:55 PM, Daniel Stoch daniel.st...@gmail.comwrote:

 Hi,

 In Wicket 1.4 the last page reference is hold in a session (is it in 6.x
 also?). So after a request has been processed all components and models


Yes. A live instance of the last used page is kept in the http session.
Actually it is a list of page instances.
All instantiated and touched pages in a request are saved for faster
retrieval for the next request.
https://cwiki.apache.org/confluence/display/WICKET/Page+Storage


 should be detached, so this last page reference should not hold transient
 LDM values. Is it true?


LDM null-yfies its transien field explicitly:
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/model/LoadableDetachableModel.java?source=cc#L104

But if your custom model uses transient that is not null-yfied in
onDetach() then it will be kept alive in the http session.



 When we are using DebugBar with SessionSizeDebugPanel, it displays session
 size and totalSize (by SessionTotalSizeModel). Does this totalSize includes
 size of object loaded by LDM or it counts all components and models size in
 detached state?


I have to check what is th difference between size and totalSize, but since
https://issues.apache.org/jira/browse/WICKET-4867 the detachable is
detached before measuring its size.



 --
 Daniel

Re: Session size vs detached models

[Daniel Stoch]

On Fri, Feb 14, 2014 at 4:12 PM, Martin Grigorov mgrigo...@apache.orgwrote:


  should be detached, so this last page reference should not hold transient
  LDM values. Is it true?
 

 LDM null-yfies its transien field explicitly:

 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/model/LoadableDetachableModel.java?source=cc#L104

 But if your custom model uses transient that is not null-yfied in
 onDetach() then it will be kept alive in the http session.


You mean in detach(), not onDetach() ;)



 
  When we are using DebugBar with SessionSizeDebugPanel, it displays
 session
  size and totalSize (by SessionTotalSizeModel). Does this totalSize
 includes
  size of object loaded by LDM or it counts all components and models size
 in
  detached state?
 

 I have to check what is th difference between size and totalSize, but since
 https://issues.apache.org/jira/browse/WICKET-4867 the detachable is
 detached before measuring its size.

 Ok, great to know. So it looks in 1.4.x totalSize is measured before
detaching.


Thanks for the answer.

--
Daniel

Re: Increasing session size

[Martijn Dashorst]

http://docs.oracle.com/javaee/1.2.1/api/javax/servlet/http/HttpSession.html#setMaxInactiveInterval(int)

On Mon, Oct 8, 2012 at 12:46 PM, shruts shruts.inn...@gmail.com wrote:
 Hi

 is there any way that we can set the session time out only for a restricted
 number of page for which login is not required.



 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/DataView-and-increasing-session-size-tp1876757p4652739.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Jochen Mader]

Get a heapdump, use yourkit/visualvm.

On Mon, Jul 16, 2012 at 11:14 AM, Ian Marshall ianmarshall...@gmail.com wrote:
 I don't think that I am getting the session size in the right place. Despite
 my session sizes being logged as very small at ~1.7kB using the Google App
 Engine (GAE) web development server, in GAE production I am getting session
 sizes approaching 1MB (and attempting to breach this GAE-imposed limit of
 1MB too).

 I shall have to try and find somewhere else to get a meaningful session
 size.



 Ian Marshall wrote

 Thanks Martin,

 I could not find onDetach() but found detach() so I have done this in my
 WebSession subclass:

   @Override
   public void detach()
   {
 long loSize = getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
 super.detach();
   }

 This seems to be fine (my sessions seem very small at ~1.7kB - I must be
 doing something wrong) except that this method can be called several times
 as a result of one request.

 Thanks again,

 Ian



 Martin Grigorov-4 wrote

 Override Session#onDetach() and do it before calling super.onDetach().

 On Fri, Jul 13, 2012 at 2:01 PM, Ian Marshall lt;IanMarshall.UK@gt;
 wrote:
 Hello,

 Is there a good way to discover my serialised or about-to-be-serialised
 session size without adding the debug bar to my page?

 I currently use

   @Override
   protected void onAfterRender()
   {
 super.onAfterRender();

 CloudSession ssnSession = (CloudSession)getSession();
 long loSize = ssnSession.getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
   }

 in my WebPage subclass, but I suspect that this is the wrong place to
 examine the session size.

 My software environment is:

 Web framework: Wicket 1.5.7
 Web server system: Google App Engine for Java version 1.7.0
 Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
 Operating system: Microsoft Windows XP Home Edition version 2002 SP3
 (version 5.1 running on x86; Cp1252; en_GB)


 Ian Marshall


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650543.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Ian Marshall]

Thanks for the tip, Jochen.

I'm already doing that now, using Oracle's Java VisualVM


Jochen Mader wrote
 
 Get a heapdump, use yourkit/visualvm.
 
 On Mon, Jul 16, 2012 at 11:14 AM, Ian Marshall lt;IanMarshall.UK@gt;
 wrote:
 I don't think that I am getting the session size in the right place.
 Despite
 my session sizes being logged as very small at ~1.7kB using the Google
 App
 Engine (GAE) web development server, in GAE production I am getting
 session
 sizes approaching 1MB (and attempting to breach this GAE-imposed limit of
 1MB too).

 I shall have to try and find somewhere else to get a meaningful session
 size.



 Ian Marshall wrote

 Thanks Martin,

 I could not find onDetach() but found detach() so I have done this in my
 WebSession subclass:

   @Override
   public void detach()
   {
 long loSize = getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
 super.detach();
   }

 This seems to be fine (my sessions seem very small at ~1.7kB - I must be
 doing something wrong) except that this method can be called several
 times
 as a result of one request.

 Thanks again,

 Ian



 Martin Grigorov-4 wrote

 Override Session#onDetach() and do it before calling super.onDetach().

 On Fri, Jul 13, 2012 at 2:01 PM, Ian Marshall lt;IanMarshall.UK@gt;
 wrote:
 Hello,

 Is there a good way to discover my serialised or
 about-to-be-serialised
 session size without adding the debug bar to my page?

 I currently use

   @Override
   protected void onAfterRender()
   {
 super.onAfterRender();

 CloudSession ssnSession = (CloudSession)getSession();
 long loSize = ssnSession.getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
   }

 in my WebPage subclass, but I suspect that this is the wrong place to
 examine the session size.

 My software environment is:

 Web framework: Wicket 1.5.7
 Web server system: Google App Engine for Java version 1.7.0
 Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
 Operating system: Microsoft Windows XP Home Edition version 2002
 SP3
 (version 5.1 running on x86; Cp1252; en_GB)


 Ian Marshall


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650543.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache

 
 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650569.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Ian Marshall]

I don't think that I am getting the session size in the right place. Despite
my session sizes being logged as very small at ~1.7kB using the Google App
Engine (GAE) web development server, in GAE production I am getting session
sizes approaching 1MB (and attempting to breach this GAE-imposed limit of
1MB too).

I shall have to try and find somewhere else to get a meaningful session
size.



Ian Marshall wrote
 
 Thanks Martin,
 
 I could not find onDetach() but found detach() so I have done this in my
 WebSession subclass:
 
   @Override
   public void detach()
   {
 long loSize = getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
 super.detach();
   }
 
 This seems to be fine (my sessions seem very small at ~1.7kB - I must be
 doing something wrong) except that this method can be called several times
 as a result of one request.
 
 Thanks again,
 
 Ian
 
 
 
 Martin Grigorov-4 wrote
 
 Override Session#onDetach() and do it before calling super.onDetach().
 
 On Fri, Jul 13, 2012 at 2:01 PM, Ian Marshall lt;IanMarshall.UK@gt;
 wrote:
 Hello,

 Is there a good way to discover my serialised or about-to-be-serialised
 session size without adding the debug bar to my page?

 I currently use

   @Override
   protected void onAfterRender()
   {
 super.onAfterRender();

 CloudSession ssnSession = (CloudSession)getSession();
 long loSize = ssnSession.getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
   }

 in my WebPage subclass, but I suspect that this is the wrong place to
 examine the session size.

 My software environment is:

 Web framework: Wicket 1.5.7
 Web server system: Google App Engine for Java version 1.7.0
 Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
 Operating system: Microsoft Windows XP Home Edition version 2002 SP3
 (version 5.1 running on x86; Cp1252; en_GB)


 Ian Marshall
 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650543.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Ian Marshall]

Hello,

Is there a good way to discover my serialised or about-to-be-serialised
session size without adding the debug bar to my page?

I currently use

  @Override
  protected void onAfterRender()
  {
super.onAfterRender();

CloudSession ssnSession = (CloudSession)getSession();
long loSize = ssnSession.getSizeInBytes();
m_logger.log(Level.FINE, String.format(Session size = %,dB., loSize));
  }

in my WebPage subclass, but I suspect that this is the wrong place to
examine the session size.

My software environment is:

Web framework: Wicket 1.5.7
Web server system: Google App Engine for Java version 1.7.0
Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
Operating system: Microsoft Windows XP Home Edition version 2002 SP3
(version 5.1 running on x86; Cp1252; en_GB)


Ian Marshall



Walter Rugora wrote
 
 Thanks Jeremy, works great!!!
 
 On 23/06/12 23:23, Jeremy Thomerson wrote:
 On Fri, Jun 22, 2012 at 11:28 PM, Walter Rugora lt;mist@gt; wrote:
 
 Hi,

 when I apply the Wicket 1.3 way to determine session size,
 RequestCycle.get().getSession().getSizeInBytes()
 it results in an around 3000bytes value in my case. And adding or
 removing Labels changed the session size.

 Now with Wicket 1.5 using
 Session.get().getSizeInBytes()
 session size is 857bytes. And I can add or remove as many Lables as I
 wish, that size stays the same. Obviously I use it wrong. Currently I
 just add the session size result to a Label added to my single WebPage:
 public HomePage(final PageParameters parameters) {
  ...
  add(new Label(ssize,
 String.valueOf(Session.get().getSizeInBytes(;
  ...
 }

 
 Here you're doing it in the constructor.  So, if this is the first page
 you
 visit there won't be any (Wicket) stuff in the session yet.
 
 Have you tried just adding the debug bar to your page?  Add a dependency
 to
 wicket-devutils in your pom.xml and then add(new DebugBar(someID)); to
 your page (and add it to the markup obviously).
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache
 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650510.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Martin Grigorov]

Override Session#onDetach() and do it before calling super.onDetach().

On Fri, Jul 13, 2012 at 2:01 PM, Ian Marshall ianmarshall...@gmail.com wrote:
 Hello,

 Is there a good way to discover my serialised or about-to-be-serialised
 session size without adding the debug bar to my page?

 I currently use

   @Override
   protected void onAfterRender()
   {
 super.onAfterRender();

 CloudSession ssnSession = (CloudSession)getSession();
 long loSize = ssnSession.getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB., loSize));
   }

 in my WebPage subclass, but I suspect that this is the wrong place to
 examine the session size.

 My software environment is:

 Web framework: Wicket 1.5.7
 Web server system: Google App Engine for Java version 1.7.0
 Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
 Operating system: Microsoft Windows XP Home Edition version 2002 SP3
 (version 5.1 running on x86; Cp1252; en_GB)


 Ian Marshall



 Walter Rugora wrote

 Thanks Jeremy, works great!!!

 On 23/06/12 23:23, Jeremy Thomerson wrote:
 On Fri, Jun 22, 2012 at 11:28 PM, Walter Rugora lt;mist@gt; wrote:

 Hi,

 when I apply the Wicket 1.3 way to determine session size,
 RequestCycle.get().getSession().getSizeInBytes()
 it results in an around 3000bytes value in my case. And adding or
 removing Labels changed the session size.

 Now with Wicket 1.5 using
 Session.get().getSizeInBytes()
 session size is 857bytes. And I can add or remove as many Lables as I
 wish, that size stays the same. Obviously I use it wrong. Currently I
 just add the session size result to a Label added to my single WebPage:
 public HomePage(final PageParameters parameters) {
  ...
  add(new Label(ssize,
 String.valueOf(Session.get().getSizeInBytes(;
  ...
 }


 Here you're doing it in the constructor.  So, if this is the first page
 you
 visit there won't be any (Wicket) stuff in the session yet.

 Have you tried just adding the debug bar to your page?  Add a dependency
 to
 wicket-devutils in your pom.xml and then add(new DebugBar(someID)); to
 your page (and add it to the markup obviously).



 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650510.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Ian Marshall]

Thanks Martin,

I could not find onDetach() but found detach() so I have done this in my
WebSession subclass:

  @Override
  public void detach()
  {
long loSize = getSizeInBytes();
m_logger.log(Level.FINE, String.format(Session size = %,dB., loSize));
super.detach();
  }

This seems to be fine (my sessions seem very small at ~1.7kB - I must be
doing something wrong) except that this method can be called several times
as a result of one request.

Thanks again,

Ian



Martin Grigorov-4 wrote
 
 Override Session#onDetach() and do it before calling super.onDetach().
 
 On Fri, Jul 13, 2012 at 2:01 PM, Ian Marshall lt;IanMarshall.UK@gt;
 wrote:
 Hello,

 Is there a good way to discover my serialised or about-to-be-serialised
 session size without adding the debug bar to my page?

 I currently use

   @Override
   protected void onAfterRender()
   {
 super.onAfterRender();

 CloudSession ssnSession = (CloudSession)getSession();
 long loSize = ssnSession.getSizeInBytes();
 m_logger.log(Level.FINE, String.format(Session size = %,dB.,
 loSize));
   }

 in my WebPage subclass, but I suspect that this is the wrong place to
 examine the session size.

 My software environment is:

 Web framework: Wicket 1.5.7
 Web server system: Google App Engine for Java version 1.7.0
 Java: 1.6.0_33; Java HotSpot(TM) Client VM 20.8-b03
 Operating system: Microsoft Windows XP Home Edition version 2002 SP3
 (version 5.1 running on x86; Cp1252; en_GB)


 Ian Marshall


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Determine-session-size-for-Wicket-1-5-tp4650050p4650513.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Walter Rugora]

Thanks Jeremy, works great!!!

On 23/06/12 23:23, Jeremy Thomerson wrote:
 On Fri, Jun 22, 2012 at 11:28 PM, Walter Rugora m...@sudus.eu wrote:
 
 Hi,

 when I apply the Wicket 1.3 way to determine session size,
 RequestCycle.get().getSession().getSizeInBytes()
 it results in an around 3000bytes value in my case. And adding or
 removing Labels changed the session size.

 Now with Wicket 1.5 using
 Session.get().getSizeInBytes()
 session size is 857bytes. And I can add or remove as many Lables as I
 wish, that size stays the same. Obviously I use it wrong. Currently I
 just add the session size result to a Label added to my single WebPage:
 public HomePage(final PageParameters parameters) {
  ...
  add(new Label(ssize, String.valueOf(Session.get().getSizeInBytes(;
  ...
 }

 
 Here you're doing it in the constructor.  So, if this is the first page you
 visit there won't be any (Wicket) stuff in the session yet.
 
 Have you tried just adding the debug bar to your page?  Add a dependency to
 wicket-devutils in your pom.xml and then add(new DebugBar(someID)); to
 your page (and add it to the markup obviously).
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Jeremy Thomerson]

On Fri, Jun 22, 2012 at 11:28 PM, Walter Rugora m...@sudus.eu wrote:

 Hi,

 when I apply the Wicket 1.3 way to determine session size,
 RequestCycle.get().getSession().getSizeInBytes()
 it results in an around 3000bytes value in my case. And adding or
 removing Labels changed the session size.

 Now with Wicket 1.5 using
 Session.get().getSizeInBytes()
 session size is 857bytes. And I can add or remove as many Lables as I
 wish, that size stays the same. Obviously I use it wrong. Currently I
 just add the session size result to a Label added to my single WebPage:
 public HomePage(final PageParameters parameters) {
  ...
  add(new Label(ssize, String.valueOf(Session.get().getSizeInBytes(;
  ...
 }


Here you're doing it in the constructor.  So, if this is the first page you
visit there won't be any (Wicket) stuff in the session yet.

Have you tried just adding the debug bar to your page?  Add a dependency to
wicket-devutils in your pom.xml and then add(new DebugBar(someID)); to
your page (and add it to the markup obviously).

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: Determine session size for Wicket 1.5

[Walter Rugora]

Hi,

when I apply the Wicket 1.3 way to determine session size,
RequestCycle.get().getSession().getSizeInBytes()
it results in an around 3000bytes value in my case. And adding or
removing Labels changed the session size.

Now with Wicket 1.5 using
Session.get().getSizeInBytes()
session size is 857bytes. And I can add or remove as many Lables as I
wish, that size stays the same. Obviously I use it wrong. Currently I
just add the session size result to a Label added to my single WebPage:
public HomePage(final PageParameters parameters) {
  ...
  add(new Label(ssize, String.valueOf(Session.get().getSizeInBytes(;
  ...
}

Where do I read the session size to get a proper result?

Thanks,
Walter

On 19/06/12 21:30, Walter Rugora wrote:
 Thanks guys!
 
 On Tue 19 Jun 2012 21:12:48 EST, Martin Grigorov wrote:
 On Tue, Jun 19, 2012 at 2:10 PM, Thomas Götz t...@decoded.de wrote:
 Session.get().getSizeInBytes();

 Apparently it is not removed ...


   -Tom


 On 19.06.2012 at 13:03 Walter Rugora wrote:

 Hi there,

 for Wicket 1.3 I determine session size like this:
 RequestCycle.get().getSession().getSizeInBytes()

 But the RequestCycle underwent some changes and I cannot figure out how
 to do it for Wicket 1.5?

 Appreciate your help!
 Walter

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Determine session size for Wicket 1.5

[Walter Rugora]

Hi there,

for Wicket 1.3 I determine session size like this:
RequestCycle.get().getSession().getSizeInBytes()

But the RequestCycle underwent some changes and I cannot figure out how
to do it for Wicket 1.5?

Appreciate your help!
Walter

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Martin Grigorov]

Hi,

This method has been removed because it just delegated to
org.apache.wicket.util.lang.WicketObjects#sizeof(Serializable)

long sessionSize = WicketObjects.sizeOf(Session.get());

On Tue, Jun 19, 2012 at 2:03 PM, Walter Rugora m...@sudus.eu wrote:
 Hi there,

 for Wicket 1.3 I determine session size like this:
 RequestCycle.get().getSession().getSizeInBytes()

 But the RequestCycle underwent some changes and I cannot figure out how
 to do it for Wicket 1.5?

 Appreciate your help!
 Walter

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Thomas Götz]

Session.get().getSizeInBytes();

   -Tom


On 19.06.2012 at 13:03 Walter Rugora wrote:

 Hi there,
 
 for Wicket 1.3 I determine session size like this:
 RequestCycle.get().getSession().getSizeInBytes()
 
 But the RequestCycle underwent some changes and I cannot figure out how
 to do it for Wicket 1.5?
 
 Appreciate your help!
 Walter

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Martin Grigorov]

On Tue, Jun 19, 2012 at 2:10 PM, Thomas Götz t...@decoded.de wrote:
 Session.get().getSizeInBytes();

Apparently it is not removed ...


   -Tom


 On 19.06.2012 at 13:03 Walter Rugora wrote:

 Hi there,

 for Wicket 1.3 I determine session size like this:
 RequestCycle.get().getSession().getSizeInBytes()

 But the RequestCycle underwent some changes and I cannot figure out how
 to do it for Wicket 1.5?

 Appreciate your help!
 Walter

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Determine session size for Wicket 1.5

[Walter Rugora]

Thanks guys!

On Tue 19 Jun 2012 21:12:48 EST, Martin Grigorov wrote:
 On Tue, Jun 19, 2012 at 2:10 PM, Thomas Götz t...@decoded.de wrote:
 Session.get().getSizeInBytes();

 Apparently it is not removed ...


   -Tom


 On 19.06.2012 at 13:03 Walter Rugora wrote:

 Hi there,

 for Wicket 1.3 I determine session size like this:
 RequestCycle.get().getSession().getSizeInBytes()

 But the RequestCycle underwent some changes and I cannot figure out how
 to do it for Wicket 1.5?

 Appreciate your help!
 Walter

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Models and Session Size

[Douglas Ferguson]

I've been working in wicket for awhile now. I was just reading this post last 
night.

http://www.small-improvements.com/10-things-about-apache-wicket-i-love/wicket:pageMapName/wicket-0

I was intrigued by the comment that more extensive use of  Model would reduce 
session size.

Why would this be? Won't models still wind up in the data graph for the Page 
and thus be in the pagemap?

Douglas

Re: Models and Session Size

[Carl-Eric Menzel]

On Tue, 19 Jun 2012 14:01:13 -0500
Douglas Ferguson the...@gmail.com wrote:

 I was intrigued by the comment that more extensive use of  Model
 would reduce session size.
 
 Why would this be? Won't models still wind up in the data graph for
 the Page and thus be in the pagemap?

Well, apart from the fact that you should pretty much always be passing
Models around in your Wicket layer rather than bare objects, I'm almost
sure that article refers to LoadableDetachableModels. Those drop all
references at the end of the request, except for something like a
database key. In the next request, the required data is loaded again on
the fly.

Carl-Eric

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Models and Session Size

[Douglas Ferguson]

Yes.. LoadableDetachable makes more sense.

Douglas

On Jun 19, 2012, at 2:17 PM, Carl-Eric Menzel wrote:

 On Tue, 19 Jun 2012 14:01:13 -0500
 Douglas Ferguson the...@gmail.com wrote:
 
 I was intrigued by the comment that more extensive use of  Model
 would reduce session size.
 
 Why would this be? Won't models still wind up in the data graph for
 the Page and thus be in the pagemap?
 
 Well, apart from the fact that you should pretty much always be passing
 Models around in your Wicket layer rather than bare objects, I'm almost
 sure that article refers to LoadableDetachableModels. Those drop all
 references at the end of the request, except for something like a
 database key. In the next request, the required data is loaded again on
 the fly.
 
 Carl-Eric
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Shrinking the session size, simply by zipping it. Saved my day.

[Emond Papegaaij]

Thanks for the suggestion! I've just implemented this. It should be available 
in 1.5.5 and 6.0.0, see https://issues.apache.org/jira/browse/WICKET-4419 for 
details.

Best regards,
Emond

On Monday 20 February 2012 10:48:52 Josh Kamau wrote:
 Thanks for the post.
 
 I wish this could be integrated into the core.
 
 Josh.
 
 On Mon, Feb 20, 2012 at 5:32 AM, robmcguinness 
 
 robert.mcguinness@gmail.com wrote:
  very nice thanks!
  
  --
  View this message in context:
  http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simp
  ly-by-zipping-it-Saved-my-day-tp4402980p4403065.html Sent from the Users
  forum mailing list archive at Nabble.com.
  
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Shrinking the session size, simply by zipping it. Saved my day.

[Josh Kamau]

Thanks Emond Papegaaij

Thats fantastic.

Josh

On Mon, Feb 20, 2012 at 7:08 PM, Emond Papegaaij emond.papega...@topicus.nl
 wrote:

 Thanks for the suggestion! I've just implemented this. It should be
 available
 in 1.5.5 and 6.0.0, see https://issues.apache.org/jira/browse/WICKET-4419for
 details.

 Best regards,
 Emond

 On Monday 20 February 2012 10:48:52 Josh Kamau wrote:
  Thanks for the post.
 
  I wish this could be integrated into the core.
 
  Josh.
 
  On Mon, Feb 20, 2012 at 5:32 AM, robmcguinness 
 
  robert.mcguinness@gmail.com wrote:
   very nice thanks!
  
   --
   View this message in context:
  
 http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simp
   ly-by-zipping-it-Saved-my-day-tp4402980p4403065.html Sent from the
 Users
   forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Shrinking the session size, simply by zipping it. Saved my day.

[Per]

Hi all,

thought I'd share a really simple hack that we're using to reduce the Wicket
session size (on Wicket 1.4). 

Background: We deploy to Google App Engine, and there's a strict 1MB limit.
We've been using LDMs and all sorts of optimisations, but we were still
reaching the limits when a user viewed long lists, or used many tabs, and as
a result pages often got evicted while still needed, resulting in ugly page
expired errors.

Turns out, you can zip the session's attributes on the way out, e.g. on
the fly, with minimal latency introduced. In over a year of squeezing bytes
out of the object graph, this had never occurred to me. But now it's kind of
obvious, and really easy to code as well... Check out our blog if you ever
had this problem.

http://smallimprove.wordpress.com/2012/02/19/reducing-wicket-session-size-to-one-third


Cheers,
Per



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simply-by-zipping-it-Saved-my-day-tp4402980p4402980.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Shrinking the session size, simply by zipping it. Saved my day.

[robmcguinness]

very nice thanks!

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simply-by-zipping-it-Saved-my-day-tp4402980p4403065.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Shrinking the session size, simply by zipping it. Saved my day.

[Josh Kamau]

Thanks for the post.

I wish this could be integrated into the core.

Josh.

On Mon, Feb 20, 2012 at 5:32 AM, robmcguinness 
robert.mcguinness@gmail.com wrote:

 very nice thanks!

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simply-by-zipping-it-Saved-my-day-tp4402980p4403065.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[nino martinez wael]

Hi Per

Very nice article. It's good for newcommers and I even saw a thing or two
thats new for me.

About  the avoid visible()! part have you tried shiro or wicket security
to manage rendering of your components, I dont know if they just do a set
visible but if they don't it would sure make the code a lot nicer.. Now
thinking of it, one could make a simple annotation or maybe something else
that would replace all components that had setVisible(false) with a
webmarkup container..

Btw are you using IOC preferly guice and have any tips for optimizing this?

regards Nino

2011/3/1 Per p...@hamburg.de

 Hi Antoine,

 I have started collecting my hints over here:

 http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

 Please note that much of it may be considered hacks and bad practice (I
 am just a Wicket user, not a Wicket master). There may be better ways to
 achieve the same results. I'd love to get feedback on these suggestions!
 So give it a shot and tell me how you went!

 Good luck!
 Per


  *bump*
 
  I'm one of those people who is reading :-)
 
 
  Antoine
 
 
  On Mon, Feb 21, 2011 at 3:11 PM, Per [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=0 wrote:
 
  
  
   Hi,
  
   I am measuring it in a profiler after the request has been completed,
   but thanks for the hint.
  
   In case anyone else is reading, I have been playing with the
   onComponentTag() and onComponentTagBody() methods on the weekend, and
   I've been able to reduce my page sizes significantly. Admittedly, this
   comes at the expense of flexibility and beauty, but I'm only doing this
   in the inner loops of very few pages, so who cares :-)  Will write a
   summary with a couple of hints once I stop drowning in work.
  
   Cheers,
   Per
  
  
Reading in the other thread that a session size of 100K or less
is achievable, I'll admit defeat now: I have not been able to shrink
   some of
my pages(!) to less than 200K, not to mention the sessions. Despite
   LDMs,
CompoundPropertyModels, and no, there are no domain objects in
   there, and no
finals.
  
   How are you measuring this? Keep in mind that if you calculate when a
   request is still processing, you might still be measuring temporary
   data (e.g. for LoadableDetachableModel, you would also measure the
   transientModelObject, and same for any proxies (Spring/ Guice) you
   might use.
  
   Eelco
  
   -
   To unsubscribe, e-mail: [hidden email]
   /user/SendEmail.jtp?type=nodenode=3316743i=0
   For additional commands, e-mail: [hidden email]
   /user/SendEmail.jtp?type=nodenode=3316743i=1
  
  
  
  
  
   If you reply to this email, your message will be added to the
   discussion below:
  
 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html?by-user=t
 
  
   To unsubscribe from Just 100K per session? That would be my dream come
   true! (Anyone here who has tuned session size before?), click here
  
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0by-user=t
 .
 
  
  
  
   --
   View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html?by-user=t
 
   Sent from the Users forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=1
   For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=2
  
  
 
  -
  To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=3
  For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=4
 
 
 
  
  If you reply to this email, your message will be added to the
  discussion below:
 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Antoine van Wel]

*bump*

I'm one of those people who is reading :-)


Antoine


On Mon, Feb 21, 2011 at 3:11 PM, Per p...@hamburg.de wrote:


 Hi,

 I am measuring it in a profiler after the request has been completed,
 but thanks for the hint.

 In case anyone else is reading, I have been playing with the
 onComponentTag() and onComponentTagBody() methods on the weekend, and
 I've been able to reduce my page sizes significantly. Admittedly, this
 comes at the expense of flexibility and beauty, but I'm only doing this
 in the inner loops of very few pages, so who cares :-)  Will write a
 summary with a couple of hints once I stop drowning in work.

 Cheers,
 Per


  Reading in the other thread that a session size of 100K or less
  is achievable, I'll admit defeat now: I have not been able to shrink
 some of
  my pages(!) to less than 200K, not to mention the sessions. Despite
 LDMs,
  CompoundPropertyModels, and no, there are no domain objects in
 there, and no
  finals.

 How are you measuring this? Keep in mind that if you calculate when a
 request is still processing, you might still be measuring temporary
 data (e.g. for LoadableDetachableModel, you would also measure the
 transientModelObject, and same for any proxies (Spring/ Guice) you
 might use.

 Eelco

 -
 To unsubscribe, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3316743i=0
 For additional commands, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3316743i=1



 
 If you reply to this email, your message will be added to the
 discussion below:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html

 To unsubscribe from Just 100K per session? That would be my dream come
 true! (Anyone here who has tuned session size before?), click here
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0.



 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Per]

Hi Antoine,

I have started collecting my hints over here:

http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

Please note that much of it may be considered hacks and bad practice (I 
am just a Wicket user, not a Wicket master). There may be better ways to 
achieve the same results. I'd love to get feedback on these suggestions! 
So give it a shot and tell me how you went!

Good luck!
Per


 *bump*

 I'm one of those people who is reading :-)


 Antoine


 On Mon, Feb 21, 2011 at 3:11 PM, Per [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=0 wrote:

 
 
  Hi,
 
  I am measuring it in a profiler after the request has been completed,
  but thanks for the hint.
 
  In case anyone else is reading, I have been playing with the
  onComponentTag() and onComponentTagBody() methods on the weekend, and
  I've been able to reduce my page sizes significantly. Admittedly, this
  comes at the expense of flexibility and beauty, but I'm only doing this
  in the inner loops of very few pages, so who cares :-)  Will write a
  summary with a couple of hints once I stop drowning in work.
 
  Cheers,
  Per
 
 
   Reading in the other thread that a session size of 100K or less
   is achievable, I'll admit defeat now: I have not been able to shrink
  some of
   my pages(!) to less than 200K, not to mention the sessions. Despite
  LDMs,
   CompoundPropertyModels, and no, there are no domain objects in
  there, and no
   finals.
 
  How are you measuring this? Keep in mind that if you calculate when a
  request is still processing, you might still be measuring temporary
  data (e.g. for LoadableDetachableModel, you would also measure the
  transientModelObject, and same for any proxies (Spring/ Guice) you
  might use.
 
  Eelco
 
  -
  To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=0
  For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=1
 
 
 
  
 
  If you reply to this email, your message will be added to the
  discussion below:
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html?by-user=t
 
  To unsubscribe from Just 100K per session? That would be my dream come
  true! (Anyone here who has tuned session size before?), click here
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0
  
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0by-user=t.
  

 
 
 
  --
  View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html?by-user=t
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=1
  For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=2
 
 

 -
 To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=3
 For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=4



 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330006.html
  

 To unsubscribe from Just 100K per session? That would be my dream come 
 true! (Anyone here who has tuned session size before?), click here 
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0.
  




-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330425.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[robert.mcguinness]

Per,

Awesome summary.  Much obliged.

Rob

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330455.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Cristi Manole]

yup, nice read. tks for sharing

onComponentTag saved my arse too in the past. Probably that's why I don't
think it's that ugly anymore :)

On Tue, Mar 1, 2011 at 2:41 PM, robert.mcguinness 
robert.mcguinness@gmail.com wrote:

 Per,

 Awesome summary.  Much obliged.

 Rob

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330455.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Antoine van Wel]

Hi Per,

easy to read, good advice... Even the easiest stuff made me wonder
whether I did that right... Excellent to see all these tips together.


Thanks a bunch!


Antoine


On Tue, Mar 1, 2011 at 8:21 PM, Per p...@hamburg.de wrote:
 Hi Antoine,

 I have started collecting my hints over here:

 http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

 Please note that much of it may be considered hacks and bad practice (I
 am just a Wicket user, not a Wicket master). There may be better ways to
 achieve the same results. I'd love to get feedback on these suggestions!
 So give it a shot and tell me how you went!

 Good luck!
 Per


 *bump*

 I'm one of those people who is reading :-)


 Antoine


 On Mon, Feb 21, 2011 at 3:11 PM, Per [hidden email]
 /user/SendEmail.jtp?type=nodenode=3330006i=0 wrote:

 
 
  Hi,
 
  I am measuring it in a profiler after the request has been completed,
  but thanks for the hint.
 
  In case anyone else is reading, I have been playing with the
  onComponentTag() and onComponentTagBody() methods on the weekend, and
  I've been able to reduce my page sizes significantly. Admittedly, this
  comes at the expense of flexibility and beauty, but I'm only doing this
  in the inner loops of very few pages, so who cares :-)  Will write a
  summary with a couple of hints once I stop drowning in work.
 
  Cheers,
  Per
 
 
   Reading in the other thread that a session size of 100K or less
   is achievable, I'll admit defeat now: I have not been able to shrink
  some of
   my pages(!) to less than 200K, not to mention the sessions. Despite
  LDMs,
   CompoundPropertyModels, and no, there are no domain objects in
  there, and no
   finals.
 
  How are you measuring this? Keep in mind that if you calculate when a
  request is still processing, you might still be measuring temporary
  data (e.g. for LoadableDetachableModel, you would also measure the
  transientModelObject, and same for any proxies (Spring/ Guice) you
  might use.
 
  Eelco
 
  -
  To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=0
  For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=1
 
 
 
 
 
  If you reply to this email, your message will be added to the
  discussion below:
 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html?by-user=t
 
  To unsubscribe from Just 100K per session? That would be my dream come
  true! (Anyone here who has tuned session size before?), click here
 
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0by-user=t.

 
 
 
  --
  View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html?by-user=t
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3330006i=1
  For additional commands, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3330006i=2
 
 

 -
 To unsubscribe, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3330006i=3
 For additional commands, e-mail: [hidden email]
 /user/SendEmail.jtp?type=nodenode=3330006i=4



 
 If you reply to this email, your message will be added to the
 discussion below:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330006.html

 To unsubscribe from Just 100K per session? That would be my dream come
 true! (Anyone here who has tuned session size before?), click here
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0.




 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[MZemeck]

Great stuff, could you let us know when you have completed a 'final' 
version so I can check back?



From:   Per p...@hamburg.de
To: users@wicket.apache.org
Date:   03/01/2011 02:22 PM
Subject:Re: Just 100K per session? That would be my dream come 
true! (Anyone here who has tuned session size before?)



Hi Antoine,

I have started collecting my hints over here:

http://www.small-improvements.com/blog/technical/tuning-wicket-session-size


Please note that much of it may be considered hacks and bad practice (I 
am just a Wicket user, not a Wicket master). There may be better ways to 
achieve the same results. I'd love to get feedback on these suggestions! 
So give it a shot and tell me how you went!

Good luck!
Per


 *bump*

 I'm one of those people who is reading :-)


 Antoine


 On Mon, Feb 21, 2011 at 3:11 PM, Per [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=0 wrote:

 
 
  Hi,
 
  I am measuring it in a profiler after the request has been completed,
  but thanks for the hint.
 
  In case anyone else is reading, I have been playing with the
  onComponentTag() and onComponentTagBody() methods on the weekend, and
  I've been able to reduce my page sizes significantly. Admittedly, this
  comes at the expense of flexibility and beauty, but I'm only doing 
this
  in the inner loops of very few pages, so who cares :-)  Will write a
  summary with a couple of hints once I stop drowning in work.
 
  Cheers,
  Per
 
 
   Reading in the other thread that a session size of 100K or less
   is achievable, I'll admit defeat now: I have not been able to 
shrink
  some of
   my pages(!) to less than 200K, not to mention the sessions. Despite
  LDMs,
   CompoundPropertyModels, and no, there are no domain objects in
  there, and no
   finals.
 
  How are you measuring this? Keep in mind that if you calculate when a
  request is still processing, you might still be measuring temporary
  data (e.g. for LoadableDetachableModel, you would also measure the
  transientModelObject, and same for any proxies (Spring/ Guice) you
  might use.
 
  Eelco
 
  -
  To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=0
  For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3316743i=1
 
 
 
  
 
  If you reply to this email, your message will be added to the
  discussion below:
  
 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html
 

 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html?by-user=t

 
  To unsubscribe from Just 100K per session? That would be my dream 
come
  true! (Anyone here who has tuned session size before?), click here
  
 
http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0
 

 
http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0by-user=t
. 

 
 
 
  --
  View this message in context: 
 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
 

 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html?by-user=t

  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=1
  For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=2
 
 

 -
 To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=3
 For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3330006i=4



 
 If you reply to this email, your message will be added to the 
 discussion below:
 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330006.html
 


 To unsubscribe from Just 100K per session? That would be my dream come 
 true! (Anyone here who has tuned session size before?), click here 
 
http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0
. 




-- 
View this message

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Cristi Manole]

I found this useful also :

http://www.small-improvements.com/10-things-about-apache-wicket-i-love/wicket:pageMapName/wicket-8

[same site, same author, kudos Per]

On Tue, Mar 1, 2011 at 3:13 PM, mzem...@osc.state.ny.us wrote:

 Great stuff, could you let us know when you have completed a 'final'
 version so I can check back?



 From:   Per p...@hamburg.de
 To: users@wicket.apache.org
 Date:   03/01/2011 02:22 PM
 Subject:Re: Just 100K per session? That would be my dream come
 true! (Anyone here who has tuned session size before?)



 Hi Antoine,

 I have started collecting my hints over here:

 http://www.small-improvements.com/blog/technical/tuning-wicket-session-size


 Please note that much of it may be considered hacks and bad practice (I
 am just a Wicket user, not a Wicket master). There may be better ways to
 achieve the same results. I'd love to get feedback on these suggestions!
 So give it a shot and tell me how you went!

 Good luck!
 Per


  *bump*
 
  I'm one of those people who is reading :-)
 
 
  Antoine
 
 
  On Mon, Feb 21, 2011 at 3:11 PM, Per [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=0 wrote:
 
  
  
   Hi,
  
   I am measuring it in a profiler after the request has been completed,
   but thanks for the hint.
  
   In case anyone else is reading, I have been playing with the
   onComponentTag() and onComponentTagBody() methods on the weekend, and
   I've been able to reduce my page sizes significantly. Admittedly, this
   comes at the expense of flexibility and beauty, but I'm only doing
 this
   in the inner loops of very few pages, so who cares :-)  Will write a
   summary with a couple of hints once I stop drowning in work.
  
   Cheers,
   Per
  
  
Reading in the other thread that a session size of 100K or less
is achievable, I'll admit defeat now: I have not been able to
 shrink
   some of
my pages(!) to less than 200K, not to mention the sessions. Despite
   LDMs,
CompoundPropertyModels, and no, there are no domain objects in
   there, and no
finals.
  
   How are you measuring this? Keep in mind that if you calculate when a
   request is still processing, you might still be measuring temporary
   data (e.g. for LoadableDetachableModel, you would also measure the
   transientModelObject, and same for any proxies (Spring/ Guice) you
   might use.
  
   Eelco
  
   -
   To unsubscribe, e-mail: [hidden email]
   /user/SendEmail.jtp?type=nodenode=3316743i=0
   For additional commands, e-mail: [hidden email]
   /user/SendEmail.jtp?type=nodenode=3316743i=1
  
  
  
  
  
   If you reply to this email, your message will be added to the
   discussion below:
  
 

 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html

  

 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html?by-user=t
 
  
   To unsubscribe from Just 100K per session? That would be my dream
 come
   true! (Anyone here who has tuned session size before?), click here
  
  

 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0

  

 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0by-user=t
 .
 
  
  
  
   --
   View this message in context:
 

 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html

  

 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html?by-user=t
 
   Sent from the Users forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=1
   For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=2
  
  
 
  -
  To unsubscribe, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=3
  For additional commands, e-mail: [hidden email]
  /user/SendEmail.jtp?type=nodenode=3330006i=4
 
 
 
  
  If you reply to this email, your message will be added to the
  discussion below:
 

 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3330006.html

Session size with ModalWindow

[Stefan Lindner]

We have a modal window (not matter Panel oder Page as content) which
holds a lot of AjaxLinks. Each time an AjaxLink is clicked the session
grows. Is there a way to suppress the versioning of the session and
page? It's the PageMap that is growing.

The ModalWindow does not hold any explicit reference to a page oder
another component on the page.

Stefan

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Session size with ModalWindow

[Martin Grigorov]

I have experienced memory problems before with Page backed ModalWindow, so
I'd recommend Panel backed.
About versioning see Component.setVersioned(false).

On Fri, Feb 25, 2011 at 11:45 AM, Stefan Lindner lind...@visionet.dewrote:

 We have a modal window (not matter Panel oder Page as content) which
 holds a lot of AjaxLinks. Each time an AjaxLink is clicked the session
 grows. Is there a way to suppress the versioning of the session and
 page? It's the PageMap that is growing.

 The ModalWindow does not hold any explicit reference to a page oder
 another component on the page.

 Stefan

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

RE: Session size with ModalWindow

[Stefan Lindner]

You're right, using a panel as modal window's content is a little bit better. 
The session grows slower but it grows infinitely. 
Setting setVersioned to false did not make any difference. Any other idea?

Stefan

-Ursprüngliche Nachricht-
Von: Martin Grigorov [mailto:mgrigo...@apache.org] 
Gesendet: Freitag, 25. Februar 2011 10:55
An: users@wicket.apache.org
Betreff: Re: Session size with ModalWindow

I have experienced memory problems before with Page backed ModalWindow, so I'd 
recommend Panel backed.
About versioning see Component.setVersioned(false).

On Fri, Feb 25, 2011 at 11:45 AM, Stefan Lindner lind...@visionet.dewrote:

 We have a modal window (not matter Panel oder Page as content) which 
 holds a lot of AjaxLinks. Each time an AjaxLink is clicked the session 
 grows. Is there a way to suppress the versioning of the session and 
 page? It's the PageMap that is growing.

 The ModalWindow does not hold any explicit reference to a page oder 
 another component on the page.

 Stefan

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Session size with ModalWindow

[Martin Grigorov]

I guess you have a cyclic reference somewhere...
You'll need to use memory analyzer to check which objects contribute to the
growing size.

See Eclipse Memory Analyzer (http://www.eclipse.org/mat/)
or jhat (comes with the JDK):

1. In jconsole - call GC
2. jmap -dump:live,format=b,file=heap.bin PID
  (captures the initial state)
3. Click on any of the links to make the session grow
4. jmap -dump:live,format=b,file=heap2.bin PID
 (captures a state with memory leak)

jhat -J-mx768m heap.bin
  (to read and analyze the heap dump)


On Fri, Feb 25, 2011 at 12:09 PM, Stefan Lindner lind...@visionet.dewrote:

 You're right, using a panel as modal window's content is a little bit
 better. The session grows slower but it grows infinitely.
 Setting setVersioned to false did not make any difference. Any other idea?

 Stefan

 -Ursprüngliche Nachricht-
 Von: Martin Grigorov [mailto:mgrigo...@apache.org]
 Gesendet: Freitag, 25. Februar 2011 10:55
 An: users@wicket.apache.org
 Betreff: Re: Session size with ModalWindow

 I have experienced memory problems before with Page backed ModalWindow, so
 I'd recommend Panel backed.
 About versioning see Component.setVersioned(false).

 On Fri, Feb 25, 2011 at 11:45 AM, Stefan Lindner lind...@visionet.de
 wrote:

  We have a modal window (not matter Panel oder Page as content) which
  holds a lot of AjaxLinks. Each time an AjaxLink is clicked the session
  grows. Is there a way to suppress the versioning of the session and
  page? It's the PageMap that is growing.
 
  The ModalWindow does not hold any explicit reference to a page oder
  another component on the page.
 
  Stefan
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

AW: Session size with ModalWindow

[Stefan Lindner]

Sigh! Ok, thank you for the below example. I will dig into the memory pool.

Stefan

-Ursprüngliche Nachricht-
Von: Martin Grigorov [mailto:mgrigo...@apache.org] 
Gesendet: Freitag, 25. Februar 2011 11:20
An: users@wicket.apache.org
Betreff: Re: Session size with ModalWindow

I guess you have a cyclic reference somewhere...
You'll need to use memory analyzer to check which objects contribute to the 
growing size.

See Eclipse Memory Analyzer (http://www.eclipse.org/mat/) or jhat (comes with 
the JDK):

1. In jconsole - call GC
2. jmap -dump:live,format=b,file=heap.bin PID
  (captures the initial state)
3. Click on any of the links to make the session grow 4. jmap 
-dump:live,format=b,file=heap2.bin PID
 (captures a state with memory leak)

jhat -J-mx768m heap.bin
  (to read and analyze the heap dump)


On Fri, Feb 25, 2011 at 12:09 PM, Stefan Lindner lind...@visionet.dewrote:

 You're right, using a panel as modal window's content is a little bit 
 better. The session grows slower but it grows infinitely.
 Setting setVersioned to false did not make any difference. Any other idea?

 Stefan

 -Ursprüngliche Nachricht-
 Von: Martin Grigorov [mailto:mgrigo...@apache.org]
 Gesendet: Freitag, 25. Februar 2011 10:55
 An: users@wicket.apache.org
 Betreff: Re: Session size with ModalWindow

 I have experienced memory problems before with Page backed 
 ModalWindow, so I'd recommend Panel backed.
 About versioning see Component.setVersioned(false).

 On Fri, Feb 25, 2011 at 11:45 AM, Stefan Lindner lind...@visionet.de
 wrote:

  We have a modal window (not matter Panel oder Page as content) which 
  holds a lot of AjaxLinks. Each time an AjaxLink is clicked the 
  session grows. Is there a way to suppress the versioning of the 
  session and page? It's the PageMap that is growing.
 
  The ModalWindow does not hold any explicit reference to a page oder 
  another component on the page.
 
  Stefan
 
  
  - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Per]

Hi,

I am measuring it in a profiler after the request has been completed, 
but thanks for the hint.

In case anyone else is reading, I have been playing with the 
onComponentTag() and onComponentTagBody() methods on the weekend, and 
I've been able to reduce my page sizes significantly. Admittedly, this 
comes at the expense of flexibility and beauty, but I'm only doing this 
in the inner loops of very few pages, so who cares :-)  Will write a 
summary with a couple of hints once I stop drowning in work.

Cheers,
Per


  Reading in the other thread that a session size of 100K or less
  is achievable, I'll admit defeat now: I have not been able to shrink 
 some of
  my pages(!) to less than 200K, not to mention the sessions. Despite 
 LDMs,
  CompoundPropertyModels, and no, there are no domain objects in 
 there, and no
  finals.

 How are you measuring this? Keep in mind that if you calculate when a
 request is still processing, you might still be measuring temporary
 data (e.g. for LoadableDetachableModel, you would also measure the
 transientModelObject, and same for any proxies (Spring/ Guice) you
 might use.

 Eelco

 -
 To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3316743i=0
 For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3316743i=1



 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3316743.html
  

 To unsubscribe from Just 100K per session? That would be my dream come 
 true! (Anyone here who has tuned session size before?), click here 
 http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3308014code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0.
  



-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3317403.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Eelco Hillenius]

 Reading in the other thread that a session size of 100K or less
 is achievable, I'll admit defeat now: I have not been able to shrink some of
 my pages(!) to less than 200K, not to mention the sessions. Despite LDMs,
 CompoundPropertyModels, and no, there are no domain objects in there, and no
 finals.

How are you measuring this? Keep in mind that if you calculate when a
request is still processing, you might still be measuring temporary
data (e.g. for LoadableDetachableModel, you would also measure the
transientModelObject, and same for any proxies (Spring/ Guice) you
might use.

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[MZemeck]

How are you storing/retrieving your photos?  I recently did some session 
size testing and I found the sessions were surprisingly small.  Once I 
removed the detachable model wrapped around an object holding a photo 
(byte array) retrieved from the database my session size shot up 
considerably.




From:   Per p...@hamburg.de
To: users@wicket.apache.org
Date:   02/16/2011 06:41 AM
Subject:Re: Just 100K per session? That would be my dream come 
true! (Anyone here who has tuned session size before?)




Hi Johan and Igor,

well, on one hand I am using App Engine, and puts are limited to 1MB. 
Even with pagination and limitation of each page to 50 users (totalling 
200Kb in memory for the whole page), I had to limit the pagemap size 
severely to ensure I am always below 1M.  In Wicket 1.5 it's a lot 
easier to write an adaptive EvictionStrategy to control memory usage, so 
I can be more flexible and evict large pages more aggressively than 
smaller ones. Still, displaying say 500 users at once will still not be 
possible if each user-row can take as much as 5K.

But I am not complaining. I knew that App Engine has this limitation, 
and I make my own product specifications, so I can live with it. On the 
plus side, App Engine (due to its restrictions) scales really well, and 
I am not worried if some day thousands of users will use my app 
concurrently. But although a typical server may have many Gigs these 
days, you'd still be in trouble if thousands of users came slurping 40M 
each, that's why I do think that session size remains an important 
consideration. I would strongly recommend anyone not to leave 
optimisation till the very last, but plan ahead and spike some of the 
most complex screens first, since Wicket *is* different in that respect.

Sorry to hear I can't optimise easily, but thanks for the quick 
responses Johan and Igor! Your support on this forum is truly 
legendary!  Will try to figure out the autoAdd() soon :-)
Per


 but if you have it down to 200K then 50 users it is nothing... thats
 10MB on memory
 If if both where 2X so 400K and 100 users thats still only 40MB in
 memory Thats for a server nothing..



 On Wed, Feb 16, 2011 at 02:10, Per [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=0 wrote:

 
 
  So I still haven't solved my memory issues, despite weeks of 
 research and
  profiling. Reading in the other thread that a session size of 100K 
 or less
  is achievable, I'll admit defeat now: I have not been able to shrink 
 some of
  my pages(!) to less than 200K, not to mention the sessions. Despite 
 LDMs,
  CompoundPropertyModels, and no, there are no domain objects in 
 there, and no
  finals.
 
  What on earth am I doing wrong?
 
  My goal is to display a long list of, say, users. Each users should 
 list a
  few labels (name, position, location, etc) and images to show who's an
  admin/poweruser. Each user has a profile picture. Each user who is 
 also a
  manager should have image icons of their subordinates' profile 
pictures
  (e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can 
quickly
  lock/unlock users, delete them, give and revoke certain rights.
 
  Despite lots of profiling each row is still 4K to 6K. This adds up 
 for even
  just 50 users. Can this be reduced, at all? I mean, it seems that 56 
 Bytes
  is the minimum for a Label, 32 for a PropertyModel, 80 for a 
 ListItem, and
  some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for 
 a label
  with 2 AttributeAppenders to also render an image), and unless the 
 whole
  list disappears from the page's object graph, all those small 
 numbers DO add
  up.
 
  My final hope was the RefreshingList, but no, it also keeps the list 
 items
  stored in the page. What I really would like is a list that does not
  maintain all its items, but throws them away, just like a LDM throws 
 away
  the domain object, and just reloads when needed. Okay, that would 
 not work
  because I want some state in there, but you get my point.
 
  I really hope it's something totally obvious I missed.
 
  Cheers,
  Per
  --
  View this message in context: 
 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html
 

 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html?by-user=t

  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=1
  For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=2
 
 

 -
 To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=3

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Johan Compagner]

but if you have it down to 200K then 50 users it is nothing... thats
10MB on memory
If if both where 2X so 400K and 100 users thats still only 40MB in
memory Thats for a server nothing..



On Wed, Feb 16, 2011 at 02:10, Per p...@hamburg.de wrote:


 So I still haven't solved my memory issues, despite weeks of research and
 profiling. Reading in the other thread that a session size of 100K or less
 is achievable, I'll admit defeat now: I have not been able to shrink some of
 my pages(!) to less than 200K, not to mention the sessions. Despite LDMs,
 CompoundPropertyModels, and no, there are no domain objects in there, and no
 finals.

 What on earth am I doing wrong?

 My goal is to display a long list of, say, users. Each users should list a
 few labels (name, position, location, etc) and images to show who's an
 admin/poweruser. Each user has a profile picture. Each user who is also a
 manager should have image icons of their subordinates' profile pictures
 (e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can quickly
 lock/unlock users, delete them, give and revoke certain rights.

 Despite lots of profiling each row is still 4K to 6K. This adds up for even
 just 50 users. Can this be reduced, at all? I mean, it seems that 56 Bytes
 is the minimum for a Label, 32 for a PropertyModel, 80 for a ListItem, and
 some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for a label
 with 2 AttributeAppenders to also render an image), and unless the whole
 list disappears from the page's object graph, all those small numbers DO add
 up.

 My final hope was the RefreshingList, but no, it also keeps the list items
 stored in the page. What I really would like is a list that does not
 maintain all its items, but throws them away, just like a LDM throws away
 the domain object, and just reloads when needed. Okay, that would not work
 because I want some state in there, but you get my point.

 I really hope it's something totally obvious I missed.

 Cheers,
 Per
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Per]

Hi Johan and Igor,

well, on one hand I am using App Engine, and puts are limited to 1MB. 
Even with pagination and limitation of each page to 50 users (totalling 
200Kb in memory for the whole page), I had to limit the pagemap size 
severely to ensure I am always below 1M.  In Wicket 1.5 it's a lot 
easier to write an adaptive EvictionStrategy to control memory usage, so 
I can be more flexible and evict large pages more aggressively than 
smaller ones. Still, displaying say 500 users at once will still not be 
possible if each user-row can take as much as 5K.

But I am not complaining. I knew that App Engine has this limitation, 
and I make my own product specifications, so I can live with it. On the 
plus side, App Engine (due to its restrictions) scales really well, and 
I am not worried if some day thousands of users will use my app 
concurrently. But although a typical server may have many Gigs these 
days, you'd still be in trouble if thousands of users came slurping 40M 
each, that's why I do think that session size remains an important 
consideration. I would strongly recommend anyone not to leave 
optimisation till the very last, but plan ahead and spike some of the 
most complex screens first, since Wicket *is* different in that respect.

Sorry to hear I can't optimise easily, but thanks for the quick 
responses Johan and Igor! Your support on this forum is truly 
legendary!  Will try to figure out the autoAdd() soon :-)
Per


 but if you have it down to 200K then 50 users it is nothing... thats
 10MB on memory
 If if both where 2X so 400K and 100 users thats still only 40MB in
 memory Thats for a server nothing..



 On Wed, Feb 16, 2011 at 02:10, Per [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=0 wrote:

 
 
  So I still haven't solved my memory issues, despite weeks of 
 research and
  profiling. Reading in the other thread that a session size of 100K 
 or less
  is achievable, I'll admit defeat now: I have not been able to shrink 
 some of
  my pages(!) to less than 200K, not to mention the sessions. Despite 
 LDMs,
  CompoundPropertyModels, and no, there are no domain objects in 
 there, and no
  finals.
 
  What on earth am I doing wrong?
 
  My goal is to display a long list of, say, users. Each users should 
 list a
  few labels (name, position, location, etc) and images to show who's an
  admin/poweruser. Each user has a profile picture. Each user who is 
 also a
  manager should have image icons of their subordinates' profile pictures
  (e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can quickly
  lock/unlock users, delete them, give and revoke certain rights.
 
  Despite lots of profiling each row is still 4K to 6K. This adds up 
 for even
  just 50 users. Can this be reduced, at all? I mean, it seems that 56 
 Bytes
  is the minimum for a Label, 32 for a PropertyModel, 80 for a 
 ListItem, and
  some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for 
 a label
  with 2 AttributeAppenders to also render an image), and unless the 
 whole
  list disappears from the page's object graph, all those small 
 numbers DO add
  up.
 
  My final hope was the RefreshingList, but no, it also keeps the list 
 items
  stored in the page. What I really would like is a list that does not
  maintain all its items, but throws them away, just like a LDM throws 
 away
  the domain object, and just reloads when needed. Okay, that would 
 not work
  because I want some state in there, but you get my point.
 
  I really hope it's something totally obvious I missed.
 
  Cheers,
  Per
  --
  View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html
  
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html?by-user=t
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=1
  For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=2
 
 

 -
 To unsubscribe, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=3
 For additional commands, e-mail: [hidden email] 
 /user/SendEmail.jtp?type=nodenode=3308586i=4



 
 If you reply to this email, your message will be added to the 
 discussion below:
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308586.html
  

 To unsubscribe from Just 100K per session? That would be my dream come 
 true! (Anyone here who has

Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Per]

So I still haven't solved my memory issues, despite weeks of research and
profiling. Reading in the other thread that a session size of 100K or less
is achievable, I'll admit defeat now: I have not been able to shrink some of
my pages(!) to less than 200K, not to mention the sessions. Despite LDMs,
CompoundPropertyModels, and no, there are no domain objects in there, and no
finals.

What on earth am I doing wrong?

My goal is to display a long list of, say, users. Each users should list a
few labels (name, position, location, etc) and images to show who's an
admin/poweruser. Each user has a profile picture. Each user who is also a
manager should have image icons of their subordinates' profile pictures
(e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can quickly
lock/unlock users, delete them, give and revoke certain rights.

Despite lots of profiling each row is still 4K to 6K. This adds up for even
just 50 users. Can this be reduced, at all? I mean, it seems that 56 Bytes
is the minimum for a Label, 32 for a PropertyModel, 80 for a ListItem, and
some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for a label
with 2 AttributeAppenders to also render an image), and unless the whole
list disappears from the page's object graph, all those small numbers DO add
up.

My final hope was the RefreshingList, but no, it also keeps the list items
stored in the page. What I really would like is a list that does not
maintain all its items, but throws them away, just like a LDM throws away
the domain object, and just reloads when needed. Okay, that would not work
because I want some state in there, but you get my point.

I really hope it's something totally obvious I missed.

Cheers,
Per
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?)

[Igor Vaynberg]

since you are using refreshingview for things you do not need to keep
across requests you can try autoAdd(component) instead of add. those
should be removed at the end of request. since refreshingview is
rebuilt those things will be readded at next render.

notice you cannot autoadd any components from page to ajaxlinks
because you need that hierarchy there.

also notice this is a pretty extreme optimization and should be
handled with care.

-igor

On Tue, Feb 15, 2011 at 5:10 PM, Per p...@hamburg.de wrote:


 So I still haven't solved my memory issues, despite weeks of research and
 profiling. Reading in the other thread that a session size of 100K or less
 is achievable, I'll admit defeat now: I have not been able to shrink some of
 my pages(!) to less than 200K, not to mention the sessions. Despite LDMs,
 CompoundPropertyModels, and no, there are no domain objects in there, and no
 finals.

 What on earth am I doing wrong?

 My goal is to display a long list of, say, users. Each users should list a
 few labels (name, position, location, etc) and images to show who's an
 admin/poweruser. Each user has a profile picture. Each user who is also a
 manager should have image icons of their subordinates' profile pictures
 (e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can quickly
 lock/unlock users, delete them, give and revoke certain rights.

 Despite lots of profiling each row is still 4K to 6K. This adds up for even
 just 50 users. Can this be reduced, at all? I mean, it seems that 56 Bytes
 is the minimum for a Label, 32 for a PropertyModel, 80 for a ListItem, and
 some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for a label
 with 2 AttributeAppenders to also render an image), and unless the whole
 list disappears from the page's object graph, all those small numbers DO add
 up.

 My final hope was the RefreshingList, but no, it also keeps the list items
 stored in the page. What I really would like is a list that does not
 maintain all its items, but throws them away, just like a LDM throws away
 the domain object, and just reloads when needed. Okay, that would not work
 because I want some state in there, but you get my point.

 I really hope it's something totally obvious I missed.

 Cheers,
 Per
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: session size

[Mihai Toma]

Hi guys!

I resolved the problem.

Here is what I was doing:

- I have a page, let's say HomePage which extends WebPage.
- This HomePage add a MenuPanel which extends Panel (add(new MenuPanel()).
- This MenuPanel add a SubmenuPanel like this menuPanel.add(new
SubmenuPanel(MenuPanel.this)).

Because of this reference the whole page was kept in session and the session
grows very fast.

You can say that I can access the MenuPanel from SubmenuPanel using
getParent() but let's omit this thing.

Is it normal for wicket to keep these pages in session if you have this type
of reference?

Thanks!


-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com] 
Sent: Monday, January 17, 2011 5:33 PM
To: users@wicket.apache.org
Subject: Re: session size

Okay, so you are storing *every* page in your page map in session.  So,
here's your next path (already partially explained by others):

1 - Consider: must you use http session store?  why?  A lot of folks *think*
that they must, and they switch to it, but they don't really need to.  Some
honestly need to.

2 - run a profiler or memory analyzer and see what's actually being held in
memory.  Probably large domain objects, or sometimes even services.

The reason you're holding these big objects is almost always one or both of
the following:

1 - improper use of models.  Not using detachable models.  Putting things
into new Model(someDomainObject).  Or holding fields references to domain
objects, or other large objects (even services).

2 - using final variables that are declared outside of an anonymous inner
class from within it (which creates a field variable in the anon-inn-class
for that object).


-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


On Mon, Jan 17, 2011 at 9:27 AM, Mihai Toma mihai.t...@asf.ro wrote:

 Yes, I use HttpSessionStore.

 -Original Message-
 From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
 Sent: Monday, January 17, 2011 5:20 PM
 To: users@wicket.apache.org
 Subject: Re: session size

 Are you using HttpSessionStore (this is not the default - which means you
 would have to explicitly set this up in your application class)?

 On Mon, Jan 17, 2011 at 8:41 AM, Martin Grigorov
 mgrigo...@apache.orgwrote:

  Try to find what is stored actually.
  Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/
 
  http://www.eclipse.org/mat/I expect that you store some bigger
  collections
  with your data with some of your components.
 
  On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:
 
   Hi!
  
  
  
   I have an application build with wicket and I have a session problem.
  
  
  
   If one user browse the application the session (the object WebSession)
   becomes bigger and bigger, so if I browse 20 pages the session size
has
   around 16 Mb.
  
   When I start browsing the session has something less than 100 Kb.
  
  
  
   I read some things about the pages which are stored in session in
  pageMaps
   and versions and I make different settings in Application class
   (getSessionSettings().setMaxPageMaps(10);
   getSessionSettings().setPageMapEvictionStrategy(new
   LeastRecentlyAccessedEvictionStrategy(10));
  
   ) but seems not to resolv my problem.
  
  
  
   Do you have any idea how can I limit the session size or how can I
 limit
   the
   number of pages stored in session?
  
  
  
   I use wicket 1.4.8.
  
  
  
   Thanks!
  
  
 



 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: session size

[Jeremy Thomerson]

On Thu, Jan 20, 2011 at 2:42 AM, Mihai Toma mihai.t...@asf.ro wrote:

 Hi guys!

 I resolved the problem.

 Here is what I was doing:

 - I have a page, let's say HomePage which extends WebPage.
 - This HomePage add a MenuPanel which extends Panel (add(new MenuPanel()).
 - This MenuPanel add a SubmenuPanel like this menuPanel.add(new
 SubmenuPanel(MenuPanel.this)).

 Because of this reference the whole page was kept in session and the
 session
 grows very fast.

 You can say that I can access the MenuPanel from SubmenuPanel using
 getParent() but let's omit this thing.

 Is it normal for wicket to keep these pages in session if you have this
 type
 of reference?


Every component has a reference to its page.  So, what you described above
should not be a problem.  And since you're using HttpSessionStore, all pages
will be serialized into session anyway.  But pages and components themselves
are not very large.  You need to run a memory analyzer and look for:

1 - references to pages or components from another page hierarchy (don't
pass one component to another page)
2 - (more likely) references to domain objects or, worse yet, services /
daos that are being serialized

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

session size

[Mihai Toma]

Hi!

 

I have an application build with wicket and I have a session problem.

 

If one user browse the application the session (the object WebSession)
becomes bigger and bigger, so if I browse 20 pages the session size has
around 16 Mb.

When I start browsing the session has something less than 100 Kb.

 

I read some things about the pages which are stored in session in pageMaps
and versions and I make different settings in Application class
(getSessionSettings().setMaxPageMaps(10);
getSessionSettings().setPageMapEvictionStrategy(new
LeastRecentlyAccessedEvictionStrategy(10));

) but seems not to resolv my problem.

 

Do you have any idea how can I limit the session size or how can I limit the
number of pages stored in session?

 

I use wicket 1.4.8.

 

Thanks!

Re: session size

[Martin Grigorov]

Try to find what is stored actually.
Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/

http://www.eclipse.org/mat/I expect that you store some bigger collections
with your data with some of your components.

On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:

 Hi!



 I have an application build with wicket and I have a session problem.



 If one user browse the application the session (the object WebSession)
 becomes bigger and bigger, so if I browse 20 pages the session size has
 around 16 Mb.

 When I start browsing the session has something less than 100 Kb.



 I read some things about the pages which are stored in session in pageMaps
 and versions and I make different settings in Application class
 (getSessionSettings().setMaxPageMaps(10);
 getSessionSettings().setPageMapEvictionStrategy(new
 LeastRecentlyAccessedEvictionStrategy(10));

 ) but seems not to resolv my problem.



 Do you have any idea how can I limit the session size or how can I limit
 the
 number of pages stored in session?



 I use wicket 1.4.8.



 Thanks!

Re: session size

[Pedro Santos]

Pages don't go to session by default, I executed the
PageMapTest#testPagemapIsNotReferencedBySession on Wicket 1.4.8 and it is
ok. I suspect you are referencing some expensive objects in an custom
session.

On Mon, Jan 17, 2011 at 12:16 PM, Mihai Toma mihai.t...@asf.ro wrote:

 Hi!



 I have an application build with wicket and I have a session problem.



 If one user browse the application the session (the object WebSession)
 becomes bigger and bigger, so if I browse 20 pages the session size has
 around 16 Mb.

 When I start browsing the session has something less than 100 Kb.



 I read some things about the pages which are stored in session in pageMaps
 and versions and I make different settings in Application class
 (getSessionSettings().setMaxPageMaps(10);
 getSessionSettings().setPageMapEvictionStrategy(new
 LeastRecentlyAccessedEvictionStrategy(10));

 ) but seems not to resolv my problem.



 Do you have any idea how can I limit the session size or how can I limit
 the
 number of pages stored in session?



 I use wicket 1.4.8.



 Thanks!




-- 
Pedro Henrique Oliveira dos Santos

Re: session size

[Jeremy Thomerson]

Are you using HttpSessionStore (this is not the default - which means you
would have to explicitly set this up in your application class)?

On Mon, Jan 17, 2011 at 8:41 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Try to find what is stored actually.
 Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/

 http://www.eclipse.org/mat/I expect that you store some bigger
 collections
 with your data with some of your components.

 On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:

  Hi!
 
 
 
  I have an application build with wicket and I have a session problem.
 
 
 
  If one user browse the application the session (the object WebSession)
  becomes bigger and bigger, so if I browse 20 pages the session size has
  around 16 Mb.
 
  When I start browsing the session has something less than 100 Kb.
 
 
 
  I read some things about the pages which are stored in session in
 pageMaps
  and versions and I make different settings in Application class
  (getSessionSettings().setMaxPageMaps(10);
  getSessionSettings().setPageMapEvictionStrategy(new
  LeastRecentlyAccessedEvictionStrategy(10));
 
  ) but seems not to resolv my problem.
 
 
 
  Do you have any idea how can I limit the session size or how can I limit
  the
  number of pages stored in session?
 
 
 
  I use wicket 1.4.8.
 
 
 
  Thanks!
 
 




-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

RE: session size

[Mihai Toma]

Yes, I use HttpSessionStore.

-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com] 
Sent: Monday, January 17, 2011 5:20 PM
To: users@wicket.apache.org
Subject: Re: session size

Are you using HttpSessionStore (this is not the default - which means you
would have to explicitly set this up in your application class)?

On Mon, Jan 17, 2011 at 8:41 AM, Martin Grigorov
mgrigo...@apache.orgwrote:

 Try to find what is stored actually.
 Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/

 http://www.eclipse.org/mat/I expect that you store some bigger
 collections
 with your data with some of your components.

 On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:

  Hi!
 
 
 
  I have an application build with wicket and I have a session problem.
 
 
 
  If one user browse the application the session (the object WebSession)
  becomes bigger and bigger, so if I browse 20 pages the session size has
  around 16 Mb.
 
  When I start browsing the session has something less than 100 Kb.
 
 
 
  I read some things about the pages which are stored in session in
 pageMaps
  and versions and I make different settings in Application class
  (getSessionSettings().setMaxPageMaps(10);
  getSessionSettings().setPageMapEvictionStrategy(new
  LeastRecentlyAccessedEvictionStrategy(10));
 
  ) but seems not to resolv my problem.
 
 
 
  Do you have any idea how can I limit the session size or how can I limit
  the
  number of pages stored in session?
 
 
 
  I use wicket 1.4.8.
 
 
 
  Thanks!
 
 




-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: session size

[Jeremy Thomerson]

Okay, so you are storing *every* page in your page map in session.  So,
here's your next path (already partially explained by others):

1 - Consider: must you use http session store?  why?  A lot of folks *think*
that they must, and they switch to it, but they don't really need to.  Some
honestly need to.

2 - run a profiler or memory analyzer and see what's actually being held in
memory.  Probably large domain objects, or sometimes even services.

The reason you're holding these big objects is almost always one or both of
the following:

1 - improper use of models.  Not using detachable models.  Putting things
into new Model(someDomainObject).  Or holding fields references to domain
objects, or other large objects (even services).

2 - using final variables that are declared outside of an anonymous inner
class from within it (which creates a field variable in the anon-inn-class
for that object).


-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


On Mon, Jan 17, 2011 at 9:27 AM, Mihai Toma mihai.t...@asf.ro wrote:

 Yes, I use HttpSessionStore.

 -Original Message-
 From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
 Sent: Monday, January 17, 2011 5:20 PM
 To: users@wicket.apache.org
 Subject: Re: session size

 Are you using HttpSessionStore (this is not the default - which means you
 would have to explicitly set this up in your application class)?

 On Mon, Jan 17, 2011 at 8:41 AM, Martin Grigorov
 mgrigo...@apache.orgwrote:

  Try to find what is stored actually.
  Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/
 
  http://www.eclipse.org/mat/I expect that you store some bigger
  collections
  with your data with some of your components.
 
  On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:
 
   Hi!
  
  
  
   I have an application build with wicket and I have a session problem.
  
  
  
   If one user browse the application the session (the object WebSession)
   becomes bigger and bigger, so if I browse 20 pages the session size has
   around 16 Mb.
  
   When I start browsing the session has something less than 100 Kb.
  
  
  
   I read some things about the pages which are stored in session in
  pageMaps
   and versions and I make different settings in Application class
   (getSessionSettings().setMaxPageMaps(10);
   getSessionSettings().setPageMapEvictionStrategy(new
   LeastRecentlyAccessedEvictionStrategy(10));
  
   ) but seems not to resolv my problem.
  
  
  
   Do you have any idea how can I limit the session size or how can I
 limit
   the
   number of pages stored in session?
  
  
  
   I use wicket 1.4.8.
  
  
  
   Thanks!
  
  
 



 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

RE: session size

[Mihai Toma]

Thanks for your recommendations.

-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com] 
Sent: Monday, January 17, 2011 5:33 PM
To: users@wicket.apache.org
Subject: Re: session size

Okay, so you are storing *every* page in your page map in session.  So,
here's your next path (already partially explained by others):

1 - Consider: must you use http session store?  why?  A lot of folks *think*
that they must, and they switch to it, but they don't really need to.  Some
honestly need to.

2 - run a profiler or memory analyzer and see what's actually being held in
memory.  Probably large domain objects, or sometimes even services.

The reason you're holding these big objects is almost always one or both of
the following:

1 - improper use of models.  Not using detachable models.  Putting things
into new Model(someDomainObject).  Or holding fields references to domain
objects, or other large objects (even services).

2 - using final variables that are declared outside of an anonymous inner
class from within it (which creates a field variable in the anon-inn-class
for that object).


-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


On Mon, Jan 17, 2011 at 9:27 AM, Mihai Toma mihai.t...@asf.ro wrote:

 Yes, I use HttpSessionStore.

 -Original Message-
 From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
 Sent: Monday, January 17, 2011 5:20 PM
 To: users@wicket.apache.org
 Subject: Re: session size

 Are you using HttpSessionStore (this is not the default - which means you
 would have to explicitly set this up in your application class)?

 On Mon, Jan 17, 2011 at 8:41 AM, Martin Grigorov
 mgrigo...@apache.orgwrote:

  Try to find what is stored actually.
  Use memory analyzer tool like Eclipse one - http://www.eclipse.org/mat/
 
  http://www.eclipse.org/mat/I expect that you store some bigger
  collections
  with your data with some of your components.
 
  On Mon, Jan 17, 2011 at 3:16 PM, Mihai Toma mihai.t...@asf.ro wrote:
 
   Hi!
  
  
  
   I have an application build with wicket and I have a session problem.
  
  
  
   If one user browse the application the session (the object WebSession)
   becomes bigger and bigger, so if I browse 20 pages the session size
has
   around 16 Mb.
  
   When I start browsing the session has something less than 100 Kb.
  
  
  
   I read some things about the pages which are stored in session in
  pageMaps
   and versions and I make different settings in Application class
   (getSessionSettings().setMaxPageMaps(10);
   getSessionSettings().setPageMapEvictionStrategy(new
   LeastRecentlyAccessedEvictionStrategy(10));
  
   ) but seems not to resolv my problem.
  
  
  
   Do you have any idea how can I limit the session size or how can I
 limit
   the
   number of pages stored in session?
  
  
  
   I use wicket 1.4.8.
  
  
  
   Thanks!
  
  
 



 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket Pattern to reduce session size

[Gaetan Zoritchak]

Hi all,

I was debugging my sessions size in order to reduce it and I saw that one of
my page spend 20ko because of an dynamic image generated with JFreeChart.
JFreeChart was serialized with my DynamicImageRessource.

My first optimisation is to make JFreeChart a static field initialized in a
static bloc.

Is it an valid way of handling that problem?

Gaetan Zoritchak,

Re: Wicket Pattern to reduce session size

[Pedro Santos]

Then this image will to be the same for all sessions. If you don't want that
object on your session, make sure at getImageData method implementation that
you are always creating your chart object, and  not keeping it in any
instance variable.


On Thu, Jan 28, 2010 at 8:28 AM, Gaetan Zoritchak 
g.zoritc...@virtual-soft.com wrote:

 Hi all,

 I was debugging my sessions size in order to reduce it and I saw that one
 of
 my page spend 20ko because of an dynamic image generated with JFreeChart.
 JFreeChart was serialized with my DynamicImageRessource.

 My first optimisation is to make JFreeChart a static field initialized in a
 static bloc.

 Is it an valid way of handling that problem?

 Gaetan Zoritchak,




-- 
Pedro Henrique Oliveira dos Santos

Re: Wicket Pattern to reduce session size

[Gaetan Zoritchak]

In fact, I just put the reference to JFreeChart as static. All the commons
values are initialized in the static bloc (ie, Font, definition on the axis,
...).

I keep the image generation done in the getImageData using the
pageParameters. So every session or even page request can have its own
version on the graph.

2010/1/28 Pedro Santos pedros...@gmail.com

 Then this image will to be the same for all sessions. If you don't want
 that
 object on your session, make sure at getImageData method implementation
 that
 you are always creating your chart object, and  not keeping it in any
 instance variable.


 On Thu, Jan 28, 2010 at 8:28 AM, Gaetan Zoritchak 
 g.zoritc...@virtual-soft.com wrote:

  Hi all,
 
  I was debugging my sessions size in order to reduce it and I saw that one
  of
  my page spend 20ko because of an dynamic image generated with JFreeChart.
  JFreeChart was serialized with my DynamicImageRessource.
 
  My first optimisation is to make JFreeChart a static field initialized in
 a
  static bloc.
 
  Is it an valid way of handling that problem?
 
  Gaetan Zoritchak,
 



 --
 Pedro Henrique Oliveira dos Santos

Re: Wicket Pattern to reduce session size

[Riyad Kalla]

Gaetan,

You can mark whatever instance that is causing the session to be so large as
'transient' to avoid it being serialized -- you'd have to recreate it each
time it was needed though. So if it's in your model:

=
private String chartName;
private String chartArguments; // maybe from a page param or something?
private transient DynamicImageResource chartImage; // won't get serialized
=

-R

On Thu, Jan 28, 2010 at 3:28 AM, Gaetan Zoritchak 
g.zoritc...@virtual-soft.com wrote:

 Hi all,

 I was debugging my sessions size in order to reduce it and I saw that one
 of
 my page spend 20ko because of an dynamic image generated with JFreeChart.
 JFreeChart was serialized with my DynamicImageRessource.

 My first optimisation is to make JFreeChart a static field initialized in a
 static bloc.

 Is it an valid way of handling that problem?

 Gaetan Zoritchak,

what's too big for a session size?

[Steve Swinsburg]

Hi all,

I'm monitoring my Wicket app via the RequestLogger and going through  
making improvements where needed. I am wondering what the size of a  
session would be before it is considered too large? Is the value given  
in the 'sessionsize' attribute of the logging output a reasonable way  
to judge what's good and what's not?


For example, on a particularly large page, rendering a list of data  
from the DB:


- 4000 items all at once, no paging = 5071985 bytes, 22854 ms
- add paging, limit to 15 items per page: 35684 bytes, 2213 ms

Obviously the latter is better, but the question is is 35k for a  
session ok? What would be the value that it becomes too large?



For reference and for anyone wondering about how to turn on the  
RequestLogger, in your Application class:

getRequestLoggerSettings().setRequestLoggerEnabled(true);


cheers,
Steve









smime.p7s
Description: S/MIME cryptographic signature

Re: what's too big for a session size?

[Martijn Dashorst]

Sessionsize recording is rather expensive, I wouldn't turn that on
unless you're hunting for something. So the request times should be
taken with a jar of salt.

Session size per se is not the only factor. A session size of 1MiB can
be perfectly ok, which would still support 1k users on one box given a
heap of  1GiB. In one of our apps we use the session to cache
component authorization keys per user. This results in sessions of
over 500kiB. In our case it is a tradeoff between speed versus
scalability.

35kiB is not much IMO.

Martijn

On Mon, Jun 15, 2009 at 1:34 PM, Steve
Swinsburgs.swinsb...@lancaster.ac.uk wrote:
 Hi all,
 I'm monitoring my Wicket app via the RequestLogger and going through making
 improvements where needed. I am wondering what
 the size of a session would be before it is considered too large? Is the value given in the 'sessionsize' attribute
 of the logging output a reasonable way to judge what's good and what's not?
 For example, on a particularly large page, rendering a list of data from the
 DB:
 - 4000 items all at once, no paging = 5071985 bytes, 22854 ms
 - add paging, limit to 15 items per page: 35684 bytes, 2213 ms
 Obviously the latter is better, but the question is is 35k for a session ok?
 What would be the value that it becomes too large?

 For reference and for anyone wondering about how to turn on the
 RequestLogger, in your Application class:
 getRequestLoggerSettings().setRequestLoggerEnabled(true);

 cheers,
 Steve










-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: what's too big for a session size?

[Igor Vaynberg]

there are two things to take into account: memory and network

like martijn said, a session is too big when it is greater then
available heap/target number of users

if you are using session replication for clustering or failover the
session is too big when the time to replicate it becomes a bottleneck.

-igor

On Mon, Jun 15, 2009 at 4:34 AM, Steve
Swinsburgs.swinsb...@lancaster.ac.uk wrote:
 Hi all,
 I'm monitoring my Wicket app via the RequestLogger and going through making
 improvements where needed. I am wondering what
 the size of a session would be before it is considered too large? Is the value given in the 'sessionsize' attribute
 of the logging output a reasonable way to judge what's good and what's not?
 For example, on a particularly large page, rendering a list of data from the
 DB:
 - 4000 items all at once, no paging = 5071985 bytes, 22854 ms
 - add paging, limit to 15 items per page: 35684 bytes, 2213 ms
 Obviously the latter is better, but the question is is 35k for a session ok?
 What would be the value that it becomes too large?

 For reference and for anyone wondering about how to turn on the
 RequestLogger, in your Application class:
 getRequestLoggerSettings().setRequestLoggerEnabled(true);

 cheers,
 Steve








-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Increasing session size

[Jürgen Lind]

 void detach() {
this.result = null;
  }

  private void performQuery() {
...
  }
}


public class DetachablePartnerAuftragModel extends
LoadableDetachableModel
{

  private Long  id;
  private AuftragBA auftragBA;

  public DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
auftragBA) {
this(auftrag.getAuftragsId(), auftragBA);
  }

  public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
this.id = id;
this.auftragBA = auftragBA;
  }

  @Override
  protected Object load() {
return this.auftragBA.findAuftragByAuftragsId(this.id);
  }

  @Override
  protected void onDetach() {
super.onDetach();
  }
}

Michael Sparer wrote:
  the objects shouldn't be serialized into the session if you're using
  loadabledetachable models, please show us some code
 
  regards,
  Michael
 
 
  Jürgen Lind-2 wrote:
  Hi,
 
  I have a question on how the DataView component is supposed to work.
In my
  application, I have to show quite large list of entities and so I am
using
  a DataView together with LoadableDetachableModels to read the data on
  demand.
  However, when looking at the serialized sessions, I can observe that
the
  session size constantly increases by a fairly large amount although I
am
  just using the navigator to page through the list. Also, when looking
into
  the serialized session, I can see that the objects that are supposed
to
  be reloaded on demand are serialized into the session as well.
 
  Is this the behavior that I would expect from the DataView or am I
making
  some mistake here?
 
  Regards,
 
  J.
 
  --
  Dr. Jürgen Lind
  iteratec GmbHFon: +49 (0)89 614551-44
  Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
  82008 Unterhaching   Web: www.iteratec.de
 
  Sitz und Registergericht der iteratec GmbH: München HRB 113 519
  Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
  -
  Michael Sparer
  http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





-
Michael Sparer
http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Increasing session size

[Johan Compagner]

 new ArrayListPartnerAuftrag(this.result).subList(first,
 first + count).iterator();
  }

  public IModel model(final Object object) {
return new DetachablePartnerAuftragModel((PartnerAuftrag) object,
 this.auftragBA);
  }

  public int size() {
if (this.result == null) {
  this.performQuery();
}
return this.result.size();
  }

  public void detach() {
this.result = null;
  }

  private void performQuery() {
...
  }
 }


 public class DetachablePartnerAuftragModel extends
 LoadableDetachableModel
 {

  private Long  id;
  private AuftragBA auftragBA;

  public DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
 auftragBA) {
this(auftrag.getAuftragsId(), auftragBA);
  }

  public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
this.id = id;
this.auftragBA = auftragBA;
  }

  @Override
  protected Object load() {
return this.auftragBA.findAuftragByAuftragsId(this.id);
  }

  @Override
  protected void onDetach() {
super.onDetach();
  }
 }

 Michael Sparer wrote:
   the objects shouldn't be serialized into the session if you're using
   loadabledetachable models, please show us some code
  
   regards,
   Michael
  
  
   Jürgen Lind-2 wrote:
   Hi,
  
   I have a question on how the DataView component is supposed to
 work.
 In my
   application, I have to show quite large list of entities and so I
 am
 using
   a DataView together with LoadableDetachableModels to read the data
 on
   demand.
   However, when looking at the serialized sessions, I can observe
 that
 the
   session size constantly increases by a fairly large amount although
 I
 am
   just using the navigator to page through the list. Also, when
 looking
 into
   the serialized session, I can see that the objects that are
 supposed
 to
   be reloaded on demand are serialized into the session as well.
  
   Is this the behavior that I would expect from the DataView or am I
 making
   some mistake here?
  
   Regards,
  
   J.
  
   --
   Dr. Jürgen Lind
   iteratec GmbHFon: +49 (0)89 614551-44
   Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
   82008 Unterhaching   Web: www.iteratec.de
  
   Sitz und Registergericht der iteratec GmbH: München HRB 113 519
   Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
  
   -
   Michael Sparer
   http://talk-on-tech.blogspot.com

 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 Michael Sparer
 http://talk-on-tech.blogspot.com

 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Increasing session size

[Jürgen Lind]

) {
   if (this.result == null) {
 this.performQuery();
   }
   return new ArrayListPartnerAuftrag(this.result).subList(first,
first + count).iterator();
 }

 public IModel model(final Object object) {
   return new DetachablePartnerAuftragModel((PartnerAuftrag) object,
this.auftragBA);
 }

 public int size() {
   if (this.result == null) {
 this.performQuery();
   }
   return this.result.size();
 }

 public void detach() {
   this.result = null;
 }

 private void performQuery() {
   ...
 }
}


public class DetachablePartnerAuftragModel extends
LoadableDetachableModel
{

 private Long  id;
 private AuftragBA auftragBA;

 public DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
auftragBA) {
   this(auftrag.getAuftragsId(), auftragBA);
 }

 public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
   this.id = id;
   this.auftragBA = auftragBA;
 }

 @Override
 protected Object load() {
   return this.auftragBA.findAuftragByAuftragsId(this.id);
 }

 @Override
 protected void onDetach() {
   super.onDetach();
 }
}

Michael Sparer wrote:
  the objects shouldn't be serialized into the session if you're using
  loadabledetachable models, please show us some code
 
  regards,
  Michael
 
 
  Jürgen Lind-2 wrote:
  Hi,
 
  I have a question on how the DataView component is supposed to
work.
In my
  application, I have to show quite large list of entities and so I
am
using
  a DataView together with LoadableDetachableModels to read the data
on
  demand.
  However, when looking at the serialized sessions, I can observe
that
the
  session size constantly increases by a fairly large amount although
I
am
  just using the navigator to page through the list. Also, when
looking
into
  the serialized session, I can see that the objects that are
supposed
to
  be reloaded on demand are serialized into the session as well.
 
  Is this the behavior that I would expect from the DataView or am I
making
  some mistake here?
 
  Regards,
 
  J.
 
  --
  Dr. Jürgen Lind
  iteratec GmbHFon: +49 (0)89 614551-44
  Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
  82008 Unterhaching   Web: www.iteratec.de
 
  Sitz und Registergericht der iteratec GmbH: München HRB 113 519
  Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel
 
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
  -
  Michael Sparer
  http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





-
Michael Sparer
http://talk-on-tech.blogspot.com


--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr

Re: Increasing session size

[Johan Compagner]

 AuftragUebersichtQuery getQuery() {
   return this.query;
  }

  public void setQuery(AuftragUebersichtQuery query) {
   this.query = query;
   this.result = null;
  }

  public IteratorPartnerAuftrag iterator(int first, int count) {
   if (this.result == null) {
 this.performQuery();
   }
   return new ArrayListPartnerAuftrag(this.result).subList(first,
 first + count).iterator();
  }

  public IModel model(final Object object) {
   return new DetachablePartnerAuftragModel((PartnerAuftrag) object,
 this.auftragBA);
  }

  public int size() {
   if (this.result == null) {
 this.performQuery();
   }
   return this.result.size();
  }

  public void detach() {
   this.result = null;
  }

  private void performQuery() {
   ...
  }
 }


 public class DetachablePartnerAuftragModel extends
 LoadableDetachableModel
 {

  private Long  id;
  private AuftragBA auftragBA;

  public DetachablePartnerAuftragModel(PartnerAuftrag auftrag,
 AuftragBA
 auftragBA) {
   this(auftrag.getAuftragsId(), auftragBA);
  }

  public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
   this.id = id;
   this.auftragBA = auftragBA;
  }

  @Override
  protected Object load() {
   return this.auftragBA.findAuftragByAuftragsId(this.id);
  }

  @Override
  protected void onDetach() {
   super.onDetach();
  }
 }

 Michael Sparer wrote:
   the objects shouldn't be serialized into the session if you're
 using
   loadabledetachable models, please show us some code
  
   regards,
   Michael
  
  
   Jürgen Lind-2 wrote:
   Hi,
  
   I have a question on how the DataView component is supposed to
 work.
 In my
   application, I have to show quite large list of entities and so I
 am
 using
   a DataView together with LoadableDetachableModels to read the
 data
 on
   demand.
   However, when looking at the serialized sessions, I can observe
 that
 the
   session size constantly increases by a fairly large amount
 although
 I
 am
   just using the navigator to page through the list. Also, when
 looking
 into
   the serialized session, I can see that the objects that are
 supposed
 to
   be reloaded on demand are serialized into the session as well.
  
   Is this the behavior that I would expect from the DataView or am
 I
 making
   some mistake here?
  
   Regards,
  
   J.
  
   --
   Dr. Jürgen Lind
   iteratec GmbHFon: +49 (0)89 614551-44
   Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
   82008 Unterhaching   Web: www.iteratec.de
  
   Sitz und Registergericht der iteratec GmbH: München HRB 113 519
   Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke,
 Ralf
 Menzel
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
  
   -
   Michael Sparer
   http://talk-on-tech.blogspot.com

 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




  -
 Michael Sparer
 http://talk-on-tech.blogspot.com

  --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



  -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


  --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44

Re: Increasing session size

[Jürgen Lind]

;

 public AuftragDataProvider(AuftragUebersichtQuery query, AuftragBA
auftragBA) {
  this.query = query;
  this.auftragBA = auftragBA;
 }

 public AuftragUebersichtQuery getQuery() {
  return this.query;
 }

 public void setQuery(AuftragUebersichtQuery query) {
  this.query = query;
  this.result = null;
 }

 public IteratorPartnerAuftrag iterator(int first, int count) {
  if (this.result == null) {
this.performQuery();
  }
  return new ArrayListPartnerAuftrag(this.result).subList(first,
first + count).iterator();
 }

 public IModel model(final Object object) {
  return new DetachablePartnerAuftragModel((PartnerAuftrag) object,
this.auftragBA);
 }

 public int size() {
  if (this.result == null) {
this.performQuery();
  }
  return this.result.size();
 }

 public void detach() {
  this.result = null;
 }

 private void performQuery() {
  ...
 }
}


public class DetachablePartnerAuftragModel extends
LoadableDetachableModel
{

 private Long  id;
 private AuftragBA auftragBA;

 public DetachablePartnerAuftragModel(PartnerAuftrag auftrag,
AuftragBA
auftragBA) {
  this(auftrag.getAuftragsId(), auftragBA);
 }

 public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
  this.id = id;
  this.auftragBA = auftragBA;
 }

 @Override
 protected Object load() {
  return this.auftragBA.findAuftragByAuftragsId(this.id);
 }

 @Override
 protected void onDetach() {
  super.onDetach();
 }
}

Michael Sparer wrote:
  the objects shouldn't be serialized into the session if you're
using
  loadabledetachable models, please show us some code
 
  regards,
  Michael
 
 
  Jürgen Lind-2 wrote:
  Hi,
 
  I have a question on how the DataView component is supposed to
work.
In my
  application, I have to show quite large list of entities and so I
am
using
  a DataView together with LoadableDetachableModels to read the
data
on
  demand.
  However, when looking at the serialized sessions, I can observe
that
the
  session size constantly increases by a fairly large amount
although
I
am
  just using the navigator to page through the list. Also, when
looking
into
  the serialized session, I can see that the objects that are
supposed
to
  be reloaded on demand are serialized into the session as well.
 
  Is this the behavior that I would expect from the DataView or am
I
making
  some mistake here?
 
  Regards,
 
  J.
 
  --
  Dr. Jürgen Lind
  iteratec GmbHFon: +49 (0)89 614551-44
  Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
  82008 Unterhaching   Web: www.iteratec.de
 
  Sitz und Registergericht der iteratec GmbH: München HRB 113 519
  Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke,
Ralf
Menzel
 
 
 
-
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
  -
  Michael Sparer
  http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




 -

Michael Sparer
http://talk-on-tech.blogspot.com

 --

Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



 -

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


 --

Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44

DataView and increasing session size

[Jürgen Lind]

Hi,

I have a question on how the DataView component is supposed to work. In my
application, I have to show quite large list of entities and so I am using
a DataView together with LoadableDetachableModels to read the data on demand.
However, when looking at the serialized sessions, I can observe that the
session size constantly increases by a fairly large amount although I am
just using the navigator to page through the list. Also, when looking into
the serialized session, I can see that the objects that are supposed to
be reloaded on demand are serialized into the session as well.

Is this the behavior that I would expect from the DataView or am I making
some mistake here?

Regards,

J.

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DataView and increasing session size

[Michael Sparer]

the objects shouldn't be serialized into the session if you're using
loadabledetachable models, please show us some code

regards,
Michael


Jürgen Lind-2 wrote:
 
 Hi,
 
 I have a question on how the DataView component is supposed to work. In my
 application, I have to show quite large list of entities and so I am using
 a DataView together with LoadableDetachableModels to read the data on
 demand.
 However, when looking at the serialized sessions, I can observe that the
 session size constantly increases by a fairly large amount although I am
 just using the navigator to page through the list. Also, when looking into
 the serialized session, I can see that the objects that are supposed to
 be reloaded on demand are serialized into the session as well.
 
 Is this the behavior that I would expect from the DataView or am I making
 some mistake here?
 
 Regards,
 
 J.
 
 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de
 
 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 


-
Michael Sparer
http://talk-on-tech.blogspot.com
-- 
View this message in context: 
http://www.nabble.com/DataView-and-increasing-session-size-tp21723557p21724558.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DataView and increasing session size

[Jürgen Lind]

.
 However, when looking at the serialized sessions, I can observe that the
 session size constantly increases by a fairly large amount although I am
 just using the navigator to page through the list. Also, when looking into
 the serialized session, I can see that the objects that are supposed to
 be reloaded on demand are serialized into the session as well.

 Is this the behavior that I would expect from the DataView or am I making
 some mistake here?

 Regards,

 J.

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





 -
 Michael Sparer
 http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DataView and increasing session size

[Michael Sparer]

 DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
 auftragBA) {
  this(auftrag.getAuftragsId(), auftragBA);
}
 
public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
  this.id = id;
  this.auftragBA = auftragBA;
}
 
@Override
protected Object load() {
  return this.auftragBA.findAuftragByAuftragsId(this.id);
}
 
@Override
protected void onDetach() {
  super.onDetach();
}
 }
 
 Michael Sparer wrote:
   the objects shouldn't be serialized into the session if you're using
   loadabledetachable models, please show us some code
  
   regards,
   Michael
  
  
   Jürgen Lind-2 wrote:
   Hi,
  
   I have a question on how the DataView component is supposed to work.
 In my
   application, I have to show quite large list of entities and so I am
 using
   a DataView together with LoadableDetachableModels to read the data on
   demand.
   However, when looking at the serialized sessions, I can observe that
 the
   session size constantly increases by a fairly large amount although I
 am
   just using the navigator to page through the list. Also, when looking
 into
   the serialized session, I can see that the objects that are supposed
 to
   be reloaded on demand are serialized into the session as well.
  
   Is this the behavior that I would expect from the DataView or am I
 making
   some mistake here?
  
   Regards,
  
   J.
  
   --
   Dr. Jürgen Lind
   iteratec GmbHFon: +49 (0)89 614551-44
   Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
   82008 Unterhaching   Web: www.iteratec.de
  
   Sitz und Registergericht der iteratec GmbH: München HRB 113 519
   Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
  
   -
   Michael Sparer
   http://talk-on-tech.blogspot.com
 
 -- 
 Mit freundlichen Grüßen,
 
 Jürgen Lind
 
 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de
 
 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 


-
Michael Sparer
http://talk-on-tech.blogspot.com
-- 
View this message in context: 
http://www.nabble.com/DataView-and-increasing-session-size-tp21723557p21725913.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DataView and increasing session size

[Jürgen Lind]

 new DetachablePartnerAuftragModel((PartnerAuftrag) object,
this.auftragBA);
   }

   public int size() {
 if (this.result == null) {
   this.performQuery();
 }
 return this.result.size();
   }

   public void detach() {
 this.result = null;
   }

   private void performQuery() {
 ...
   }
}


public class DetachablePartnerAuftragModel extends LoadableDetachableModel
{

   private Long  id;
   private AuftragBA auftragBA;

   public DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
auftragBA) {
 this(auftrag.getAuftragsId(), auftragBA);
   }

   public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
 this.id = id;
 this.auftragBA = auftragBA;
   }

   @Override
   protected Object load() {
 return this.auftragBA.findAuftragByAuftragsId(this.id);
   }

   @Override
   protected void onDetach() {
 super.onDetach();
   }
}

Michael Sparer wrote:
  the objects shouldn't be serialized into the session if you're using
  loadabledetachable models, please show us some code
 
  regards,
  Michael
 
 
  Jürgen Lind-2 wrote:
  Hi,
 
  I have a question on how the DataView component is supposed to work.
In my
  application, I have to show quite large list of entities and so I am
using
  a DataView together with LoadableDetachableModels to read the data on
  demand.
  However, when looking at the serialized sessions, I can observe that
the
  session size constantly increases by a fairly large amount although I
am
  just using the navigator to page through the list. Also, when looking
into
  the serialized session, I can see that the objects that are supposed
to
  be reloaded on demand are serialized into the session as well.
 
  Is this the behavior that I would expect from the DataView or am I
making
  some mistake here?
 
  Regards,
 
  J.
 
  --
  Dr. Jürgen Lind
  iteratec GmbHFon: +49 (0)89 614551-44
  Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
  82008 Unterhaching   Web: www.iteratec.de
 
  Sitz und Registergericht der iteratec GmbH: München HRB 113 519
  Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
  -
  Michael Sparer
  http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
Michael Sparer
http://talk-on-tech.blogspot.com


--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Increasing session size

[Jürgen Lind]

 DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
auftragBA) {
 this(auftrag.getAuftragsId(), auftragBA);
   }

   public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
 this.id = id;
 this.auftragBA = auftragBA;
   }

   @Override
   protected Object load() {
 return this.auftragBA.findAuftragByAuftragsId(this.id);
   }

   @Override
   protected void onDetach() {
 super.onDetach();
   }
}

Michael Sparer wrote:
  the objects shouldn't be serialized into the session if you're using
  loadabledetachable models, please show us some code
 
  regards,
  Michael
 
 
  Jürgen Lind-2 wrote:
  Hi,
 
  I have a question on how the DataView component is supposed to work.
In my
  application, I have to show quite large list of entities and so I am
using
  a DataView together with LoadableDetachableModels to read the data on
  demand.
  However, when looking at the serialized sessions, I can observe that
the
  session size constantly increases by a fairly large amount although I
am
  just using the navigator to page through the list. Also, when looking
into
  the serialized session, I can see that the objects that are supposed
to
  be reloaded on demand are serialized into the session as well.
 
  Is this the behavior that I would expect from the DataView or am I
making
  some mistake here?
 
  Regards,
 
  J.
 
  --
  Dr. Jürgen Lind
  iteratec GmbHFon: +49 (0)89 614551-44
  Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
  82008 Unterhaching   Web: www.iteratec.de
 
  Sitz und Registergericht der iteratec GmbH: München HRB 113 519
  Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
Menzel
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
  -
  Michael Sparer
  http://talk-on-tech.blogspot.com

--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
Michael Sparer
http://talk-on-tech.blogspot.com


--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Increasing session size

[Igor Vaynberg]

() {
 this.result = null;
   }

   private void performQuery() {
 ...
   }
 }


 public class DetachablePartnerAuftragModel extends
 LoadableDetachableModel
 {

   private Long  id;
   private AuftragBA auftragBA;

   public DetachablePartnerAuftragModel(PartnerAuftrag auftrag, AuftragBA
 auftragBA) {
 this(auftrag.getAuftragsId(), auftragBA);
   }

   public DetachablePartnerAuftragModel(Long id, AuftragBA auftragBA) {
 this.id = id;
 this.auftragBA = auftragBA;
   }

   @Override
   protected Object load() {
 return this.auftragBA.findAuftragByAuftragsId(this.id);
   }

   @Override
   protected void onDetach() {
 super.onDetach();
   }
 }

 Michael Sparer wrote:
   the objects shouldn't be serialized into the session if you're using
   loadabledetachable models, please show us some code
  
   regards,
   Michael
  
  
   Jürgen Lind-2 wrote:
   Hi,
  
   I have a question on how the DataView component is supposed to work.
 In my
   application, I have to show quite large list of entities and so I am
 using
   a DataView together with LoadableDetachableModels to read the data on
   demand.
   However, when looking at the serialized sessions, I can observe that
 the
   session size constantly increases by a fairly large amount although I
 am
   just using the navigator to page through the list. Also, when looking
 into
   the serialized session, I can see that the objects that are supposed
 to
   be reloaded on demand are serialized into the session as well.
  
   Is this the behavior that I would expect from the DataView or am I
 making
   some mistake here?
  
   Regards,
  
   J.
  
   --
   Dr. Jürgen Lind
   iteratec GmbHFon: +49 (0)89 614551-44
   Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
   82008 Unterhaching   Web: www.iteratec.de
  
   Sitz und Registergericht der iteratec GmbH: München HRB 113 519
   Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf
 Menzel
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
  
   -
   Michael Sparer
   http://talk-on-tech.blogspot.com

 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





 -
 Michael Sparer
 http://talk-on-tech.blogspot.com

 --
 Mit freundlichen Grüßen,

 Jürgen Lind

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Monitor session size in Tomcat

[Adriano dos Santos Fernandes]

Hi!

This is not a direct wicket question, but important for wicket usage, so 
I'm asking here...


What you use to monitor Tomcat sessions size? (preferable something that 
I can use in production)


I tried with JMX/jconsole and with LambdaProbe. The former doesn't seems 
to have that info, and the later probably enters in cycle, because 
estimate sizes nevers end for a session just established.


Thanks,


Adriano


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Monitor session size in Tomcat

[Johan Compagner]

you can monitor what wicket does with the IRequestLogger

On Mon, Dec 1, 2008 at 16:13, Adriano dos Santos Fernandes 
[EMAIL PROTECTED] wrote:

 Hi!

 This is not a direct wicket question, but important for wicket usage, so
 I'm asking here...

 What you use to monitor Tomcat sessions size? (preferable something that I
 can use in production)

 I tried with JMX/jconsole and with LambdaProbe. The former doesn't seems to
 have that info, and the later probably enters in cycle, because estimate
 sizes nevers end for a session just established.

 Thanks,


 Adriano


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Monitor session size in Tomcat

[Adriano dos Santos Fernandes]

So does that mean there is nothing already made to monitor session size 
at container level instead of  application level?



Adriano


Johan Compagner escreveu:

you can monitor what wicket does with the IRequestLogger

On Mon, Dec 1, 2008 at 16:13, Adriano dos Santos Fernandes 
[EMAIL PROTECTED] wrote:

  

Hi!

This is not a direct wicket question, but important for wicket usage, so
I'm asking here...

What you use to monitor Tomcat sessions size? (preferable something that I
can use in production)

I tried with JMX/jconsole and with LambdaProbe. The former doesn't seems to
have that info, and the later probably enters in cycle, because estimate
sizes nevers end for a session just established.

Thanks,


Adriano


-
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: Best way to debug big session size?

[Timo Rantalaiho]

On Thu, 10 Jul 2008, Johan Compagner wrote:
 try it with yourkit?

I've got JProfiler and at least with that it's been a bit 
difficult to pinpoint which exactly are the components 
hanging onto the biggest objects.

But I did a kludge in our own DiskPageStore extension where
I visit all the components of the page to be stored and
print out the component path and
Objects.sizeof(component.getModel()) for each component.

It seems to produce pretty informative output. I'm a bit
unsure of whether it's entirely safe to call getModel() as
late as saving the page after detach (getModelObject()
definitely not :)) so maybe I'll remove this when I'm done
with debugging / adding missing detaching.

This also revealed that for example the page instance I'm
currently looking at has more than 2000 components in total
:) Maybe we should look at replacing some stuff that is not 
displayed with dummy WebMarkupContainers instead of relying 
on visibility control.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Best way to debug big session size?

[Eelco Hillenius]

 This also revealed that for example the page instance I'm
 currently looking at has more than 2000 components in total
 :) Maybe we should look at replacing some stuff that is not
 displayed with dummy WebMarkupContainers instead of relying
 on visibility control.

Maurice and Martijn have a similar war story they might share...
something about a component with excel like functionality :-)

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Best way to debug big session size?

[Johan Compagner]

try it with yourkit?

i know it is still a bit of work but normally if you do a request and after
the request you look at the HttpSession
and see how big it is, you should be able to pin point the biggest retained
size

johan


On Thu, Jul 10, 2008 at 5:24 AM, Timo Rantalaiho [EMAIL PROTECTED]
wrote:

 Hello,

 I'm currently debugging a situation where we have too much
 data in the session (in some places, more objects should be
 behind detachable models, smaller object graphs retrieved
 from the db etc). I've added debug logging to get the size
 of the page just before storing it in DiskPageStore (i.e.
 after it has been detach()ed) and sometimes stopped it in
 debugger to inspect the page content, surfed the children in
 the debugger view etc.

 But I don't find an easy way to find out which particular
 part of the component hierarchy is consuming a lot of
 memory, because the whole component tree is bidirectional
 (if you do Objects.sizeof(foo) you get the exactly same
 result for that as for the parent or any child of foo()).

 Any ideas?

 Logging the page size in DiskPageStore if debug level is
 enabled could be a good addition btw.

 Best wishes,
 Timo


 P.S. Matej, thanks for the help the other day on the
 detach() issue. Our models were detaching just fine, but one
 had a dangerous toString() implementation doing getObject()
 which in turn did a reattach, and this messed things up in
 the debugging session :)

 --
 Timo Rantalaiho
 Reaktor Innovations OyURL: http://www.ri.fi/ 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Best way to debug big session size?

[Timo Rantalaiho]

Hello,

I'm currently debugging a situation where we have too much
data in the session (in some places, more objects should be
behind detachable models, smaller object graphs retrieved
from the db etc). I've added debug logging to get the size
of the page just before storing it in DiskPageStore (i.e.
after it has been detach()ed) and sometimes stopped it in
debugger to inspect the page content, surfed the children in
the debugger view etc.

But I don't find an easy way to find out which particular
part of the component hierarchy is consuming a lot of
memory, because the whole component tree is bidirectional
(if you do Objects.sizeof(foo) you get the exactly same
result for that as for the parent or any child of foo()).

Any ideas?

Logging the page size in DiskPageStore if debug level is
enabled could be a good addition btw.

Best wishes,
Timo


P.S. Matej, thanks for the help the other day on the
detach() issue. Our models were detaching just fine, but one
had a dangerous toString() implementation doing getObject()
which in turn did a reattach, and this messed things up in
the debugging session :)

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Sporadic exponential explosion of session size

[Meetesh Karia]

Hi all,

We're running into a problem that we've seen happen many times though 
unfortunately we can't consistently reproduce it.  We're using Wicket 
1.3.1 with automatic multi-window support enabled and the default 
SecondLevelCacheSessionStore.


During normal use of our site, no Pages reference other Pages and the 
session size changes as it should.  However, occasionally when we open 
pages in a new tab (often when multiple pages are opened in a new tab in 
rapid succession), we get the following situation:


1 tab

pagemap-null size = x

2 tabs

pagemap-null size = 2x
pagemap-0 size = x

3 tabs

pagemap-null size = 4x
pagemap-0 size = 2x
pagemap-1 size = x

4 tabs

pagemap-null size = 8x
pagemap-0 size = 4x
pagemap-1 size = 2x
pagemap-2 size = x


The only explanation that I could come up with for this explosion is 
that somehow, behind the scenes, a Page is holding onto a reference to 
another Page in this situation.  Because 8x is beyond our max pagemap 
size, it means that there can only be 1-2 Pages in it taking up this space.


Has anyone come across a problem like this?  Any thoughts on what this 
could be?


Thanks,
Meetesh

Re: Sporadic exponential explosion of session size

[Igor Vaynberg]

please file a bug report so this doesnt fall through the cracks.
reference this email thread in this issue report through nabble or
whatever...

-igor


On Fri, Feb 29, 2008 at 8:59 AM, Meetesh Karia [EMAIL PROTECTED] wrote:
 There's nothing obvious and we don't hold references between pages
  intentionally.  Additionally, when we use the site normally (ie, without
  opening new tabs), we don't run into this problem (and I would expect us
  to if we were holding references to Pages).

  Is it possible that the automatic multi-window javascript is executing
  before the response is completely written (don't know if wicket flushes
  the response buffer in parts for large pages) which causes the redirect
  to happen before the response completes?  Perhaps that keeps a
  threadlocal variable from being cleaned up somewhere?

  I'm just speculating here ...

  Meetesh



  Matej Knopp wrote:
   Wicket shouldn't implicitely hold any page references. Are you sure
   you don't have references between your pages?
  
   -Matej
  
   On Fri, Feb 29, 2008 at 3:29 PM, Meetesh Karia [EMAIL PROTECTED] wrote:
  
   Hi all,
  
We're running into a problem that we've seen happen many times though
unfortunately we can't consistently reproduce it.  We're using Wicket
1.3.1 with automatic multi-window support enabled and the default
SecondLevelCacheSessionStore.
  
During normal use of our site, no Pages reference other Pages and the
session size changes as it should.  However, occasionally when we open
pages in a new tab (often when multiple pages are opened in a new tab in
rapid succession), we get the following situation:
  
1 tab
  
pagemap-null size = x
  
2 tabs
  
pagemap-null size = 2x
pagemap-0 size = x
  
3 tabs
  
pagemap-null size = 4x
pagemap-0 size = 2x
pagemap-1 size = x
  
4 tabs
  
pagemap-null size = 8x
pagemap-0 size = 4x
pagemap-1 size = 2x
pagemap-2 size = x
  
  
The only explanation that I could come up with for this explosion is
that somehow, behind the scenes, a Page is holding onto a reference to
another Page in this situation.  Because 8x is beyond our max pagemap
size, it means that there can only be 1-2 Pages in it taking up this 
 space.
  
Has anyone come across a problem like this?  Any thoughts on what this
could be?
  
Thanks,
Meetesh
  
  
  
  
  
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sporadic exponential explosion of session size

[Meetesh Karia]

Will do and I will respond with any other information we find as we're 
looking into this as well.


Meetesh

Igor Vaynberg wrote:

please file a bug report so this doesnt fall through the cracks.
reference this email thread in this issue report through nabble or
whatever...

-igor


On Fri, Feb 29, 2008 at 8:59 AM, Meetesh Karia [EMAIL PROTECTED] wrote:
  

There's nothing obvious and we don't hold references between pages
 intentionally.  Additionally, when we use the site normally (ie, without
 opening new tabs), we don't run into this problem (and I would expect us
 to if we were holding references to Pages).

 Is it possible that the automatic multi-window javascript is executing
 before the response is completely written (don't know if wicket flushes
 the response buffer in parts for large pages) which causes the redirect
 to happen before the response completes?  Perhaps that keeps a
 threadlocal variable from being cleaned up somewhere?

 I'm just speculating here ...

 Meetesh



 Matej Knopp wrote:
  Wicket shouldn't implicitely hold any page references. Are you sure
  you don't have references between your pages?
 
  -Matej
 
  On Fri, Feb 29, 2008 at 3:29 PM, Meetesh Karia [EMAIL PROTECTED] wrote:
 
  Hi all,
 
   We're running into a problem that we've seen happen many times though
   unfortunately we can't consistently reproduce it.  We're using Wicket
   1.3.1 with automatic multi-window support enabled and the default
   SecondLevelCacheSessionStore.
 
   During normal use of our site, no Pages reference other Pages and the
   session size changes as it should.  However, occasionally when we open
   pages in a new tab (often when multiple pages are opened in a new tab in
   rapid succession), we get the following situation:
 
   1 tab
 
   pagemap-null size = x
 
   2 tabs
 
   pagemap-null size = 2x
   pagemap-0 size = x
 
   3 tabs
 
   pagemap-null size = 4x
   pagemap-0 size = 2x
   pagemap-1 size = x
 
   4 tabs
 
   pagemap-null size = 8x
   pagemap-0 size = 4x
   pagemap-1 size = 2x
   pagemap-2 size = x
 
 
   The only explanation that I could come up with for this explosion is
   that somehow, behind the scenes, a Page is holding onto a reference to
   another Page in this situation.  Because 8x is beyond our max pagemap
   size, it means that there can only be 1-2 Pages in it taking up this space.
 
   Has anyone come across a problem like this?  Any thoughts on what this
   could be?
 
   Thanks,
   Meetesh
 
 
 
 
 
 

Re: Sporadic exponential explosion of session size

[Johan Compagner]

please do and also try to attach a quickstart.

On Fri, Feb 29, 2008 at 11:02 PM, Meetesh Karia [EMAIL PROTECTED]
wrote:

 Will do and I will respond with any other information we find as we're
 looking into this as well.

 Meetesh

 Igor Vaynberg wrote:
  please file a bug report so this doesnt fall through the cracks.
  reference this email thread in this issue report through nabble or
  whatever...
 
  -igor
 
 
  On Fri, Feb 29, 2008 at 8:59 AM, Meetesh Karia [EMAIL PROTECTED]
 wrote:
 
  There's nothing obvious and we don't hold references between pages
   intentionally.  Additionally, when we use the site normally (ie,
 without
   opening new tabs), we don't run into this problem (and I would expect
 us
   to if we were holding references to Pages).
 
   Is it possible that the automatic multi-window javascript is executing
   before the response is completely written (don't know if wicket
 flushes
   the response buffer in parts for large pages) which causes the
 redirect
   to happen before the response completes?  Perhaps that keeps a
   threadlocal variable from being cleaned up somewhere?
 
   I'm just speculating here ...
 
   Meetesh
 
 
 
   Matej Knopp wrote:
Wicket shouldn't implicitely hold any page references. Are you sure
you don't have references between your pages?
   
-Matej
   
On Fri, Feb 29, 2008 at 3:29 PM, Meetesh Karia 
 [EMAIL PROTECTED] wrote:
   
Hi all,
   
 We're running into a problem that we've seen happen many times
 though
 unfortunately we can't consistently reproduce it.  We're using
 Wicket
 1.3.1 with automatic multi-window support enabled and the default
 SecondLevelCacheSessionStore.
   
 During normal use of our site, no Pages reference other Pages and
 the
 session size changes as it should.  However, occasionally when we
 open
 pages in a new tab (often when multiple pages are opened in a new
 tab in
 rapid succession), we get the following situation:
   
 1 tab
   
 pagemap-null size = x
   
 2 tabs
   
 pagemap-null size = 2x
 pagemap-0 size = x
   
 3 tabs
   
 pagemap-null size = 4x
 pagemap-0 size = 2x
 pagemap-1 size = x
   
 4 tabs
   
 pagemap-null size = 8x
 pagemap-0 size = 4x
 pagemap-1 size = 2x
 pagemap-2 size = x
   
   
 The only explanation that I could come up with for this explosion
 is
 that somehow, behind the scenes, a Page is holding onto a
 reference to
 another Page in this situation.  Because 8x is beyond our max
 pagemap
 size, it means that there can only be 1-2 Pages in it taking up
 this space.
   
 Has anyone come across a problem like this?  Any thoughts on what
 this
 could be?
   
 Thanks,
 Meetesh
   
   
   
   
   
   
 
 

Re: Session size is constantly increasing on setResponsePage(getPage())

[Johan Compagner]

are you talking about 1.2 or 1.3?

in 1.2 a session could grow a little bit because we have there max 7 pages
that all also can contain some version info.

But as you said when you do setResponsePage(Page.class) everything drops to
normal
that means that you have to use 1.3 because then the newly created page
replaces the old one in the session memory.

But if you set in the link click the same page that the link is on
(setResponsePage(getPage()).  You see a grow?

That seems a bit strange. need to check that out then.

johan


On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:


 Hi there,

 we're developing a rather straight forward application with wicket and I
 am
 wondering if it is ok to call setResponsePage(getPage()) inside the
 onClick() method of a Link? Because the session size is constantly
 increasing, here's my example:

 Application class:

 public class TestApplication extends WebApplication {
public TestApplication() {
super();
}
@Override
public Class getHomePage() {
return TestPage.class;
}
@Override
protected void init() {
super.init();
mountBookmarkablePage(/home, getHomePage());
}
 }

 Page class:

 public class TestPage extends WebPage {
public TestPage() {
super();
setVersioned(false);
add(new TestLink(testLink));
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
System.err.println(getSession().getSizeInBytes());
}
 }

 Link class:

 public class TestLink extends Link {
public TestLink(String id) {
super(id);
}
@Override
public void onClick() {
setResponsePage(getPage());
}
 }

 Everytime the Link is clicked the session size increases a bit (it may be
 tiny in this test application, it's nevertheless increasing constantly).
 Whenever (this clue comes from testing our real application) a new page is
 constructed (be it via setResponsePage(Page.class) or via url) the session
 size falls back to normal. When an older instance (via back button or
 link)
 is used, the session is as big as before.

 I also noticed that when using TabbedPanel (from wicket-extensions) each
 tab
 change (out of the box) increases the session size much more.

 All our models are LoadableDetachableModels, so our model objects are all
 transient and should never be stored in the session. Of course we use here
 and there a new PropertyModel() and other wrapper models, but only in
 constructors.

 Any suggestion what we could do about it? In the real application the
 increment is about 2-3Kb per click, which will become a problem since the
 application is click-intensive and collaborative (many session at the same
 time).

 Thanks in advance,
 Martin


 --
 View this message in context:
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
 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: Session size is constantly increasing on setResponsePage(getPage())

[Johan Compagner]

ok found it, We are leaking auto add html header containers.

Looking to fix it.


On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:

 are you talking about 1.2 or 1.3?

 in 1.2 a session could grow a little bit because we have there max 7 pages
 that all also can contain some version info.

 But as you said when you do setResponsePage(Page.class) everything drops
 to normal
 that means that you have to use 1.3 because then the newly created page
 replaces the old one in the session memory.

 But if you set in the link click the same page that the link is on
 (setResponsePage(getPage()).  You see a grow?

 That seems a bit strange. need to check that out then.

 johan


  On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
 
 
  Hi there,
 
  we're developing a rather straight forward application with wicket and I
  am
  wondering if it is ok to call setResponsePage(getPage()) inside the
  onClick() method of a Link? Because the session size is constantly
  increasing, here's my example:
 
  Application class:
 
  public class TestApplication extends WebApplication {
 public TestApplication() {
 super();
 }
 @Override
 public Class getHomePage() {
 return TestPage.class;
 }
 @Override
 protected void init() {
 super.init();
 mountBookmarkablePage(/home, getHomePage());
 }
  }
 
  Page class:
 
  public class TestPage extends WebPage {
 public TestPage() {
 super();
 setVersioned(false);
 add(new TestLink(testLink));
 }
 @Override
 protected void onBeforeRender() {
 super.onBeforeRender();
 System.err.println(getSession().getSizeInBytes());
 }
  }
 
  Link class:
 
  public class TestLink extends Link {
 public TestLink(String id) {
 super(id);
 }
 @Override
 public void onClick() {
 setResponsePage(getPage());
 }
  }
 
  Everytime the Link is clicked the session size increases a bit (it may
  be
  tiny in this test application, it's nevertheless increasing constantly).
 
  Whenever (this clue comes from testing our real application) a new page
  is
  constructed (be it via setResponsePage(Page.class) or via url) the
  session
  size falls back to normal. When an older instance (via back button or
  link)
  is used, the session is as big as before.
 
  I also noticed that when using TabbedPanel (from wicket-extensions) each
  tab
  change (out of the box) increases the session size much more.
 
  All our models are LoadableDetachableModels, so our model objects are
  all
  transient and should never be stored in the session. Of course we use
  here
  and there a new PropertyModel() and other wrapper models, but only in
  constructors.
 
  Any suggestion what we could do about it? In the real application the
  increment is about 2-3Kb per click, which will become a problem since
  the
  application is click-intensive and collaborative (many session at the
  same
  time).
 
  Thanks in advance,
  Martin
 
 
  --
  View this message in context: 
  http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
 
  Sent from the Wicket - User mailing list archive at 
  Nabble.comhttp://nabble.com/
  .
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

Re: Session size is constantly increasing on setResponsePage(getPage())

[Martin2]

Hi,

thanks for the quick response. Should I open a JIRA issue for this or is it
to minor to justify the overhead? 

bw,
Martin





Johan Compagner wrote:
 
 ok found it, We are leaking auto add html header containers.
 
 Looking to fix it.
 
 
 On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:

 are you talking about 1.2 or 1.3?

 in 1.2 a session could grow a little bit because we have there max 7
 pages
 that all also can contain some version info.

 But as you said when you do setResponsePage(Page.class) everything drops
 to normal
 that means that you have to use 1.3 because then the newly created page
 replaces the old one in the session memory.

 But if you set in the link click the same page that the link is on
 (setResponsePage(getPage()).  You see a grow?

 That seems a bit strange. need to check that out then.

 johan


  On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
 
 
  Hi there,
 
  we're developing a rather straight forward application with wicket and
 I
  am
  wondering if it is ok to call setResponsePage(getPage()) inside the
  onClick() method of a Link? Because the session size is constantly
  increasing, here's my example:
 
  Application class:
 
  public class TestApplication extends WebApplication {
 public TestApplication() {
 super();
 }
 @Override
 public Class getHomePage() {
 return TestPage.class;
 }
 @Override
 protected void init() {
 super.init();
 mountBookmarkablePage(/home, getHomePage());
 }
  }
 
  Page class:
 
  public class TestPage extends WebPage {
 public TestPage() {
 super();
 setVersioned(false);
 add(new TestLink(testLink));
 }
 @Override
 protected void onBeforeRender() {
 super.onBeforeRender();
 System.err.println(getSession().getSizeInBytes());
 }
  }
 
  Link class:
 
  public class TestLink extends Link {
 public TestLink(String id) {
 super(id);
 }
 @Override
 public void onClick() {
 setResponsePage(getPage());
 }
  }
 
  Everytime the Link is clicked the session size increases a bit (it may
  be
  tiny in this test application, it's nevertheless increasing
 constantly).
 
  Whenever (this clue comes from testing our real application) a new page
  is
  constructed (be it via setResponsePage(Page.class) or via url) the
  session
  size falls back to normal. When an older instance (via back button or
  link)
  is used, the session is as big as before.
 
  I also noticed that when using TabbedPanel (from wicket-extensions)
 each
  tab
  change (out of the box) increases the session size much more.
 
  All our models are LoadableDetachableModels, so our model objects are
  all
  transient and should never be stored in the session. Of course we use
  here
  and there a new PropertyModel() and other wrapper models, but only in
  constructors.
 
  Any suggestion what we could do about it? In the real application the
  increment is about 2-3Kb per click, which will become a problem since
  the
  application is click-intensive and collaborative (many session at the
  same
  time).
 
  Thanks in advance,
  Martin
 
 
  --
  View this message in context:
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
 
  Sent from the Wicket - User mailing list archive at
 Nabble.comhttp://nabble.com/
  .
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 
 

-- 
View this message in context: 
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13018499
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: Session size is constantly increasing on setResponsePage(getPage())

[Gerolf Seitz]

i think johan already fixed it in trunk.

gerolf

On 10/3/07, Martin2 [EMAIL PROTECTED] wrote:


 Hi,

 thanks for the quick response. Should I open a JIRA issue for this or is
 it
 to minor to justify the overhead?

 bw,
 Martin





 Johan Compagner wrote:
 
  ok found it, We are leaking auto add html header containers.
 
  Looking to fix it.
 
 
  On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:
 
  are you talking about 1.2 or 1.3?
 
  in 1.2 a session could grow a little bit because we have there max 7
  pages
  that all also can contain some version info.
 
  But as you said when you do setResponsePage(Page.class) everything
 drops
  to normal
  that means that you have to use 1.3 because then the newly created page
  replaces the old one in the session memory.
 
  But if you set in the link click the same page that the link is on
  (setResponsePage(getPage()).  You see a grow?
 
  That seems a bit strange. need to check that out then.
 
  johan
 
 
   On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
  
  
   Hi there,
  
   we're developing a rather straight forward application with wicket
 and
  I
   am
   wondering if it is ok to call setResponsePage(getPage()) inside the
   onClick() method of a Link? Because the session size is constantly
   increasing, here's my example:
  
   Application class:
  
   public class TestApplication extends WebApplication {
  public TestApplication() {
  super();
  }
  @Override
  public Class getHomePage() {
  return TestPage.class;
  }
  @Override
  protected void init() {
  super.init();
  mountBookmarkablePage(/home, getHomePage());
  }
   }
  
   Page class:
  
   public class TestPage extends WebPage {
  public TestPage() {
  super();
  setVersioned(false);
  add(new TestLink(testLink));
  }
  @Override
  protected void onBeforeRender() {
  super.onBeforeRender();
  System.err.println(getSession().getSizeInBytes());
  }
   }
  
   Link class:
  
   public class TestLink extends Link {
  public TestLink(String id) {
  super(id);
  }
  @Override
  public void onClick() {
  setResponsePage(getPage());
  }
   }
  
   Everytime the Link is clicked the session size increases a bit (it
 may
   be
   tiny in this test application, it's nevertheless increasing
  constantly).
  
   Whenever (this clue comes from testing our real application) a new
 page
   is
   constructed (be it via setResponsePage(Page.class) or via url) the
   session
   size falls back to normal. When an older instance (via back button or
   link)
   is used, the session is as big as before.
  
   I also noticed that when using TabbedPanel (from wicket-extensions)
  each
   tab
   change (out of the box) increases the session size much more.
  
   All our models are LoadableDetachableModels, so our model objects are
   all
   transient and should never be stored in the session. Of course we use
   here
   and there a new PropertyModel() and other wrapper models, but only in
   constructors.
  
   Any suggestion what we could do about it? In the real application the
   increment is about 2-3Kb per click, which will become a problem since
   the
   application is click-intensive and collaborative (many session at the
   same
   time).
  
   Thanks in advance,
   Martin
  
  
   --
   View this message in context:
 
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
  
   Sent from the Wicket - User mailing list archive at
  Nabble.comhttp://nabble.com/
   .
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13018499
 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: Session size is constantly increasing on setResponsePage(getPage())

[Johan Compagner]

jip, but open and close a jira if you want to have this in the change list..

On 10/3/07, Gerolf Seitz [EMAIL PROTECTED] wrote:

 i think johan already fixed it in trunk.

 gerolf

 On 10/3/07, Martin2 [EMAIL PROTECTED] wrote:
 
 
  Hi,
 
  thanks for the quick response. Should I open a JIRA issue for this or is
  it
  to minor to justify the overhead?
 
  bw,
  Martin
 
 
 
 
 
  Johan Compagner wrote:
  
   ok found it, We are leaking auto add html header containers.
  
   Looking to fix it.
  
  
   On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:
  
   are you talking about 1.2 or 1.3?
  
   in 1.2 a session could grow a little bit because we have there max 7
   pages
   that all also can contain some version info.
  
   But as you said when you do setResponsePage(Page.class) everything
  drops
   to normal
   that means that you have to use 1.3 because then the newly created
 page
   replaces the old one in the session memory.
  
   But if you set in the link click the same page that the link is on
   (setResponsePage(getPage()).  You see a grow?
  
   That seems a bit strange. need to check that out then.
  
   johan
  
  
On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
   
   
Hi there,
   
we're developing a rather straight forward application with wicket
  and
   I
am
wondering if it is ok to call setResponsePage(getPage()) inside the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:
   
Application class:
   
public class TestApplication extends WebApplication {
   public TestApplication() {
   super();
   }
   @Override
   public Class getHomePage() {
   return TestPage.class;
   }
   @Override
   protected void init() {
   super.init();
   mountBookmarkablePage(/home, getHomePage());
   }
}
   
Page class:
   
public class TestPage extends WebPage {
   public TestPage() {
   super();
   setVersioned(false);
   add(new TestLink(testLink));
   }
   @Override
   protected void onBeforeRender() {
   super.onBeforeRender();
   System.err.println(getSession().getSizeInBytes());
   }
}
   
Link class:
   
public class TestLink extends Link {
   public TestLink(String id) {
   super(id);
   }
   @Override
   public void onClick() {
   setResponsePage(getPage());
   }
}
   
Everytime the Link is clicked the session size increases a bit (it
  may
be
tiny in this test application, it's nevertheless increasing
   constantly).
   
Whenever (this clue comes from testing our real application) a new
  page
is
constructed (be it via setResponsePage(Page.class) or via url) the
session
size falls back to normal. When an older instance (via back button
 or
link)
is used, the session is as big as before.
   
I also noticed that when using TabbedPanel (from wicket-extensions)
   each
tab
change (out of the box) increases the session size much more.
   
All our models are LoadableDetachableModels, so our model objects
 are
all
transient and should never be stored in the session. Of course we
 use
here
and there a new PropertyModel() and other wrapper models, but only
 in
constructors.
   
Any suggestion what we could do about it? In the real application
 the
increment is about 2-3Kb per click, which will become a problem
 since
the
application is click-intensive and collaborative (many session at
 the
same
time).
   
Thanks in advance,
Martin
   
   
--
View this message in context:
  
 
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
   
Sent from the Wicket - User mailing list archive at
   Nabble.comhttp://nabble.com/
.
   
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13018499
  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: Session size is constantly increasing on setResponsePage(getPage())

[Martin2]

I'm using trunk right now and the issue is resolved, the session size does
not increase anymore when setting the response page. Since this was a
critical one on our issue tracking, thanks for the quick fix.

I opened jira  https://issues.apache.org/jira/browse/WICKET-1036 WICKET-1036 
and I'll close it then.

bw,
Martin


Johan Compagner wrote:
 
 jip, but open and close a jira if you want to have this in the change
 list..
 
 On 10/3/07, Gerolf Seitz [EMAIL PROTECTED] wrote:

 i think johan already fixed it in trunk.

 gerolf

 On 10/3/07, Martin2 [EMAIL PROTECTED] wrote:
 
 
  Hi,
 
  thanks for the quick response. Should I open a JIRA issue for this or
 is
  it
  to minor to justify the overhead?
 
  bw,
  Martin
 
 
 
 
 
  Johan Compagner wrote:
  
   ok found it, We are leaking auto add html header containers.
  
   Looking to fix it.
  
  
   On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:
  
   are you talking about 1.2 or 1.3?
  
   in 1.2 a session could grow a little bit because we have there max 7
   pages
   that all also can contain some version info.
  
   But as you said when you do setResponsePage(Page.class) everything
  drops
   to normal
   that means that you have to use 1.3 because then the newly created
 page
   replaces the old one in the session memory.
  
   But if you set in the link click the same page that the link is on
   (setResponsePage(getPage()).  You see a grow?
  
   That seems a bit strange. need to check that out then.
  
   johan
  
  
On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
   
   
Hi there,
   
we're developing a rather straight forward application with wicket
  and
   I
am
wondering if it is ok to call setResponsePage(getPage()) inside
 the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:
   
Application class:
   
public class TestApplication extends WebApplication {
   public TestApplication() {
   super();
   }
   @Override
   public Class getHomePage() {
   return TestPage.class;
   }
   @Override
   protected void init() {
   super.init();
   mountBookmarkablePage(/home, getHomePage());
   }
}
   
Page class:
   
public class TestPage extends WebPage {
   public TestPage() {
   super();
   setVersioned(false);
   add(new TestLink(testLink));
   }
   @Override
   protected void onBeforeRender() {
   super.onBeforeRender();
   System.err.println(getSession().getSizeInBytes());
   }
}
   
Link class:
   
public class TestLink extends Link {
   public TestLink(String id) {
   super(id);
   }
   @Override
   public void onClick() {
   setResponsePage(getPage());
   }
}
   
Everytime the Link is clicked the session size increases a bit (it
  may
be
tiny in this test application, it's nevertheless increasing
   constantly).
   
Whenever (this clue comes from testing our real application) a new
  page
is
constructed (be it via setResponsePage(Page.class) or via url) the
session
size falls back to normal. When an older instance (via back button
 or
link)
is used, the session is as big as before.
   
I also noticed that when using TabbedPanel (from
 wicket-extensions)
   each
tab
change (out of the box) increases the session size much more.
   
All our models are LoadableDetachableModels, so our model objects
 are
all
transient and should never be stored in the session. Of course we
 use
here
and there a new PropertyModel() and other wrapper models, but only
 in
constructors.
   
Any suggestion what we could do about it? In the real application
 the
increment is about 2-3Kb per click, which will become a problem
 since
the
application is click-intensive and collaborative (many session at
 the
same
time).
   
Thanks in advance,
Martin
   
   
--
View this message in context:
  
 
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
   
Sent from the Wicket - User mailing list archive at
   Nabble.comhttp://nabble.com/
.
   
   
   
 -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13018499
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail

Session size is constantly increasing on setResponsePage(getPage())

[Martin2]

Hi there,

we're developing a rather straight forward application with wicket and I am
wondering if it is ok to call setResponsePage(getPage()) inside the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:

Application class:

public class TestApplication extends WebApplication {
public TestApplication() {
super();
}
@Override
public Class getHomePage() {
return TestPage.class;
}
@Override
protected void init() {
super.init();
mountBookmarkablePage(/home, getHomePage());
}
}

Page class:

public class TestPage extends WebPage {
public TestPage() {
super();
setVersioned(false);
add(new TestLink(testLink));
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
System.err.println(getSession().getSizeInBytes());
}
}

Link class:

public class TestLink extends Link {
public TestLink(String id) {
super(id);
}
@Override
public void onClick() {
setResponsePage(getPage());
}
}

Everytime the Link is clicked the session size increases a bit (it may be
tiny in this test application, it's nevertheless increasing constantly).
Whenever (this clue comes from testing our real application) a new page is
constructed (be it via setResponsePage(Page.class) or via url) the session
size falls back to normal. When an older instance (via back button or link)
is used, the session is as big as before.

I also noticed that when using TabbedPanel (from wicket-extensions) each tab
change (out of the box) increases the session size much more.

All our models are LoadableDetachableModels, so our model objects are all
transient and should never be stored in the session. Of course we use here
and there a new PropertyModel() and other wrapper models, but only in
constructors.

Any suggestion what we could do about it? In the real application the
increment is about 2-3Kb per click, which will become a problem since the
application is click-intensive and collaborative (many session at the same
time).

Thanks in advance,
Martin


-- 
View this message in context: 
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]