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