I have added the code to remove objects from the hibernate session cache
(i.e. the use of evict() method). I have checked that it is run each time.
This has no affect, to prove it I ran some tests with and without this code.
I was not convinced that it would have an affect since I am running two
production systems which have run for months without ever being stopped with
very similar Spring / Hibernate configurations.
I decided to run some fairly crude tests to see if the OutOfMemoryError's
were repeatable, these were as follows:
1) Run the same search (which produces the maximum set 5000 results) every
time not leaving the search page. The search returned 7 successful results
and returned an OutOfMemoryError on the 8 search.
2) Same search as 1) but left the search page after first successful render
of results and then repeat each search again without leaving the search
page. The search returned 5 successful results and returned an
OutOfMemoryError on the 6 search.
3) Same search as 1) but left the search page after each successful render
of results and then repeat each search again when leaving the search page
always went to the same page. The search returned 3 successful results and
returned an OutOfMemoryError on the 4 search.
The page which was moved to after the search page was the home page which
had no persistent objects fetched using Spring / Hibernate.
The above is repeatable every time I do the same tests. Adding the evict
object code in spring / hibernate code has no affect.
Is it fair to say that since the number of pages that can be successfully
rendered before an OutOfMemoryError exception occurs is reduced by changing
pages the problem resides at the presentation (Tapestry) level.
Any thoughts?
Paul
Patrick Casey <[EMAIL PROTECTED]> wrote:
That looks like it'd work, yep. Dunno if the Hibernate session is
the root of your bug, but A) it might be and B) that looks like it'll clear
it out.
--- Pat
-----Original Message-----
From: seloha . [mailto:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 1:15 PM
To: tapestry-user@jakarta.apache.org
Subject: RE: OutOfMemoryError Tapestry 4.0
Pat,
So in my case then since the Hibernate session is controlled by Spring
after
getting the large list I could subsequently call a method in my DAO which
looks something like this:
public void clearSessionObjects(List bigList) {
Iterator bigListIt = bigList.iterator();
while (bigListIt.hasNext()) {
getHibernateTemplate().evict(bigListIt.next);
}
}
And without such an eviction this could be what is causing the
OutOfMemoryError.
regards,
Paul
Patrick Casey <[EMAIL PROTECTED]>
To clean out a hibernate session:
s.clear();
That will clean everything out of it. Be warned though that it
clears *everything* out of it, not just the stuff you recently loaded. A
safer way is to evict each object one at a time as you load it e.g.
Sesison s = HibHelper.getSession();
Query q = s.createQuery("from bigList");
List l = q.list();
For (int x=0; x< l.size(); x++)
s.evict(l.get(x));
>-----Original Message-----
>From: seloha . [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 26, 2005 12:45 PM
>To: tapestry-user@jakarta.apache.org
>Subject: RE: OutOfMemoryError Tapestry 4.0
>
>Pat,
>
>1) Yes I am setting the object list to null.
>
>2) I have not put a log statement in the code to check it but I have set
a
>break point in debug mode and each time the page was rendered the code in
>pageDetached(PageEvent event) was run.
>
>3) There is no other code which references the list object except the
>rendering using the For component.
>
>4) Subsequent to adding the pageDetached(PageEvent event) I have not run
>it
>on with the caching enabled. This I will do next.
>
>5) I am using hibernate for the persistent layer. I have always just let
>Spring look after the hibernate session using declarative transactions
and
>have never bypassed this mechanism. How do I evict go about evicting the
>objects after the transaction which picks them up. Can I just write a
>piece
>of code in my DAO which after picking the objects up then has something
>like:
>
>getHibernateTemplate().evict(objects);
>
>As you can see I am fairly nieve about use of hibernate too.
>
>
>Thanks,
>
>Paul
>
>
>Patrick Casey <[EMAIL PROTECTED]> wrote:
>
> Well, it really smells to me like a leak, largely because 5,000
>objects, while a pain in the posterior to scroll through, is mouse nuts
>from
>a memory use standpoint (say each object is 10k (a whopper of an object),
>we're only looking at 50 M of memory here. Most object though are at
least
>an order of magnitude smaller than that.
>
> Just to reinterate though:
>
> It loads once fine.
> If you keep loading the page, eventually you get an EOM error,
>right?
>
> Some other things to look at:
>
>1) Unless Howard changed things or I'm remembering wrong, initial-value
>*does not* reset object to that state. Rather it's the value at page
>creation, not the value that something gets set to when a page goes into
>or
>out of the pool. So to null something out after render, you need to
>explicitly set it to null in the detach code (as it appears you are
>doing).
>
>2) Can you put a log statement or something similar in your page detatch
>listener to make sure it's being called? I don't know how many times I
got
>bit by adding PageBeginRender methods to Tap 3 forms without remembering
>to
>add implements PageEventListener to the class.
>
>3) Are there any other object (statics, the visit object, some other
>property on the page) which reference your object chain?
>
>4) Do you still get the EOM with tapestry's cache turned off? If so, it's
>not your tapestry code that's hanging onto a reference. If not, then the
>problem lies in not re-iniitalizing something properly before a page goes
>back into the pool.
>
>5) Are you using Hibernate as your persistence layer? If so, are you
>evicting these objects out of the session and/or loading them in a temp
>session which you are subsequently closing? Objects loaded in a Hibernate
>session have the lifespan of the session, regardless of whether or not
>your
>code holds a reference to them.
>
>
>
> >-----Original Message-----
> >From: seloha . [mailto:[EMAIL PROTECTED]
> >Sent: Monday, September 26, 2005 11:55 AM
> >To: tapestry-user@jakarta.apache.org
> >Subject: RE: OutOfMemoryError Tapestry 4.0
> >
> >Thanks Pat,
> >
> >One thing I was not doing which you pointed out was setting the list to
> >null
> >in pageDetached(PageEvent event) so I added this and also included
> >System.gc(). This unfortunately had no affect. The list uses abstract
> >getter
> >and setter and is initialized in the .page spec with
> >initial-value="ognl:null".
> >
> >I have a number of selection models for PropertySelection components
>which
> >are initialized lazily which I am not resetting to null each time (but
> >there
> >are only about 100 total items in these objects). Could these have any
> >affect.
> >
> >I am really poking around in the dark. Similar Spring and Hibernate
> >mechanism that I wrote using Tapestry 3.0.3 is on a production system
and
> >has run with no problems for months. Admittedly I never go and display
> >5000
> >objects at once though!
> >
> >I cannot see that I am inadvertently holding onto any objects in the
code
> >but you never know?
> >
> >Thanks again for your help,
> >
> >Paul
> >
> >
> >Patrick Casey <[EMAIL PROTECTED]> wrote:
> >
> > It sounds like a memory leak, but it could just be a slow garbage
> >collector as well. Try adding:
> >
> > System.gc() to the end of your transaction to guarantee the garbage
> >collector runs after each page render. Then see if repeated page
renders
> >still blow out your memory. If they do, then I suspect that somehow you
> >(or
> >tapestry, or spring) is hanging onto a reference to those object after
> >page
> >completion.
> >
> > --- Pat
> >
> > PS You *are* resetting your page properties to null (and nulling out
> >the list of 5000 items) on the page's post-render cleanup phase, right?
> >
> > >-----Original Message-----
> > >From: seloha . [mailto:[EMAIL PROTECTED]
> > >Sent: Monday, September 26, 2005 3:11 AM
> > >To: tapestry-user@jakarta.apache.org
> > >Subject: OutOfMemoryError Tapestry 4.0
> > >
> > >I have a page which allows a user to search the database based on
>various
> > >criteria. I have restricted the number of returned items to 5000. I
> > >display
> > >the items in the same search page using the @For component with
> > >volatile="ognl:true" . Repeated searches which return 5000 items will
> > >result
> > >in an OutOfMemoryError exception. If I leave the page and then return
>or
> > >stay on the page I will ultimately get an OutOfMemoryError exception.
> > >
> > >I can view other pages after this exception but a repeat of trying to
> > >display 5000 items on this page will display an OutOfMemory
exception.
> > >
> > >The only way to clear this problem is to restart the servlet
container.
> > >This
> > >fails using either Jetty or Tomcat in both development and production
> > >environments (using different operating systems).
> > >
> > >All the variables displaying the list are explicitly declared in the
> >.page
> > >specification and using initial-value set to null.
> > >
> > >I am using Tapestry 4.0 beta 8.
> > >
> > >The data is retrieved using Spring and Hibernate (no fancy patterns,
> > >standard Spring declarative transactions and using
> >getHibernateTemplate())
> > >and mapped to Tapestry using hivemodule.xml:
> > >
> > > <implementation service-
> > >id="hivemind.lib.DefaultSpringBeanFactoryHolder">
> > > <invoke-factory>
> > > <construct autowire-services="false"
> > >class="uk.co.cymbol.tair.tapestry.AppSpringBeanFactoryHolderImpl">
> > > <event-listener service-id="hivemind.ShutdownCoordinator" />
> > > <set-object property="context"
> > >value="service:tapestry.globals.WebContext" />
> > > </construct>
> > > </invoke-factory>
> > > </implementation>
> > >
> > >and injecting the appropriate Spring bean.
> > >
> > >I am completely confused as to how to tie down the problem and
isolate
> > >which
> > >section of code is causing the problem.
> > >
> > >Any help would be much appreciated.
> > >
> > >Paul
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: tapestry-user-
[EMAIL PROTECTED]
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >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]
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail:
>
>
>
>---------------------------------------------------------------------
>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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
