RE: Barracuda: Re:Barracuda Memory troubles

Thanks Christian.  We looked at caching components in the session and
abandon it, numerous reasons, the obvious one is that invalidating selective
sub-trees of the DOM does you no good.

What we are doing now is caching enough state from the models that make up
the page to determine if the page is fresh or not, sending an Etag to the
browser, listening at the page level to the model events and invalidating
the Etag.

What this does is allow us to push the caching out into the browser (where
it belongs).  So far it's working great.  Barracuda gives us the advantage
of being able to build reusable components, like Swing has.  


> -----Original Message-----
> From: Christian Cryder [mailto:[email protected]]
> Sent: Monday, December 09, 2002 11:02 AM
> To: [email protected]
> Subject: RE: Barracuda: Re:Barracuda Memory troubles
> 
> 
> Hi Steve!
> 
> > This may seem like a stupid question but...
> 
> Nah...no such think as a stupid question, except maybe for 
> the one that
> doesn't get asked ;-)
> 
> > I think I'm missing something quite basic about how Barracuda is
> > supposed to
> > work.  What state should be saved in the session:
> >  1) The models (almost certainly)
> >  2) The BComponent tree (seems of little value without #3)
> >  3) The rendered DOM tree.
> 
> Well, first of all, I want to say that in practice here at 
> ATMReports we
> don't keep any of these beyond a single req-resp lifecycle. 
> If we did want
> to cache something, we would not cache the model but rather 
> the data that
> backs the model, and then just create a new model (using that 
> same data as
> input) for every request.
> 
> > If the BComponent's are not being kept past the request / 
> response cycle
> > why would they care about changes to the model? That is if 
> you create a
> > new BComponent to construct a page it starts out invalid so 
> you should
> > never see the valid state in a BComponent?
> 
> If you are not caching components, then I think you are correct - the
> hierarchy is always invalidated, so it doesn't really matter. 
> The component
> model does, however, allow for caching of components (as per 
> the BConfig
> example) - I don't really recommend doing it this way, but it 
> is doable, and
> that's why the model notification is in there.
> 
> That help?
> 
> Christian
> 
> ----------------------------------------------
> Christian Cryder [[email protected]]
> Internet Architect, ATMReports.com
> Barracuda - http://barracuda.enhydra.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
> 
> 
> > -----Original Message-----
> > From: [email protected] 
> [mailto:[email protected]]On
> > Behalf Of Mayhew, Steve
> > Sent: Monday, December 09, 2002 12:17 PM
> > To: '[email protected]'
> > Subject: RE: Barracuda: Re:Barracuda Memory troubles
> >
> >
> >
> > This may seem like a stupid question but... If the 
> BComponent's are not
> > being kept past the request / response cycle why would they 
> care about
> > changes to the model?   That is if you create a new BComponent to
> > construct
> > a page it starts out invalid so you should never see the 
> valid state in a
> > BComponent?
> >
> > I think I'm missing something quite basic about how Barracuda is
> > supposed to
> > work.  What state should be saved in the session:
> >  1) The models (almost certainly)
> >  2) The BComponent tree (seems of little value without #3)
> >  3) The rendered DOM tree.
> >
> > Unless we are to surgically update the DOM on the browser it seems a
> > rendered DOM tree is either entirely valid or entirely invalid...
> >  The only
> > choice is to return a complete HTML page to the client or 
> status 304 (if
> > client does a conditional GET)
> >
> > Given this why have the BComponents listen to models at all?
> >
> > One approach might be to make the model's reference to listeners a
> > WeakReference, that way once the BComponent that references 
> them is no
> > longer strongly referenced then it will be GC'd and the 
> WeakReference will
> > be null'd.  Model can simply ingore (or better remove from 
> the list) any
> > weakly reachable (get() returns null) BComponent objects.
> >
> > Just my random thoughts.
> >
> >
> > > -----Original Message-----
> > > From: Vas Skrypnyk [mailto:[email protected]]
> > > Sent: Sunday, December 08, 2002 11:44 PM
> > > To: [email protected]
> > > Subject: RE: Barracuda: Re:Barracuda Memory troubles
> > >
> > >
> > > Hi Christian,
> > >
> > > >Hi Bill,
> > > >
> > > >So it sounds like you release your handle to the BTemplate,
> > > but the Model
> > > >still has a reference to it, which in turn would keep the
> > > BTemplate (and any
> > > >components it contains) from being
> > > >gc'd, since your model still has
> > > >references to them. Is that correct?
> > >
> > > That's correct.
> > >
> > > >It almost sounds like when a component calls the
> > > destroyCycle() method, it
> > > >needs a mechanism to disconnect any models which might
> > > >be listening to that
> > > >component. Thoughts?
> > >
> > > That sounds right. If destroyCycle() is called as the
> > > finalization code on the BTemplate object then, since it has
> > > references to all its models it should be able to disconnect
> > > itself. It will still be possible to hook in the same model
> > > to the same BTemplate and get the listener connection
> > > replicated, but, I suppose, the programmers should take some
> > > responsibility for their code :))
> > >
> > > Cheers,
> > > --Bill.
> > >
> > > >Christian
> > > >----------------------------------------------
> > > >Christian Cryder [[email protected]]
> > > >Internet Architect, ATMReports.com
> > > >Barracuda - http:
> > > >//barracuda.enhydra.org
> > > >----------------------------------------------
> > > >"Coffee? I could quit anytime, just not today"
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: [email protected] [mailto:barracuda-
> > > >[email protected]]On
> > > >> Behalf Of V B Skrypnyk
> > > >> Sent: Saturday, December 07, 2002 10:17 PM
> > > >> To: [email protected]
> > > >> Subject: Barracuda: Re:Barracuda Memory troubles
> > > >>
> > > >>
> > > >> Christian,
> > > >>
> > > >>
> > > >I have found where the memory leak was happening in my code. It
> > > >> is caused by the following scenario:
> > > >>
> > > >> 1. Create a BTemplate that will last for one servlet lifecycle
> > > >> (MainScreen).
> > > >> 2. Create
> > > >a Model that represents some persistent data and store
> > > >> it in the session (Tabs)
> > > >> 3. Have different portions of your application access
> > > >> session-saved Model and set up their data in it. (Tabs)
> > > >
> > > >> 4. On every MainScreen instantiation add the model, so that the
> > > >> respective portion of the template is rendered, i.e. Tabs.
> > > >>
> > > >> What happens now is that on every addModel() call a 
> new listener
> > > >
> > > >> is added to the model and the list keeps growing until 
> the model
> > > >> drags around megabytes of listeners, as happened in my case.
> > > >>
> > > >> Now, maybe instead of appending the listeners in the List it is
> > > >
> > > >> worthwhile checking if this listener has already been added, or
> > > >> maybe I am misusing the Barracuda framework.
> > > >>
> > > >> Please let me know what you think.
> > > >>
> > > >> Cheers,
> > > >> --Bill.
> > > >> _______________________________________________
> > > >
> > > >> Barracuda mailing list
> > > >> [email protected]
> > > >> http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> > > >> FAQ - http://www.jguru.com/faq/Barracuda
> > > >
> > > >_______________________________________________
> > > >
> > > >Barracuda mailing list
> > > >[email protected]
> > > >http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> > > >FAQ - http://www.jguru.com/faq/Barracuda
> > > >
> > > _______________________________________________
> > > Barracuda mailing list
> > > [email protected]
> > > http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> > > FAQ - http://www.jguru.com/faq/Barracuda
> > >
> > _______________________________________________
> > Barracuda mailing list
> > [email protected]
> > http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> > FAQ - http://www.jguru.com/faq/Barracuda
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> FAQ - http://www.jguru.com/faq/Barracuda
> 
_______________________________________________
Barracuda mailing list
[email protected]
http://www.enhydra.org/mailman/listinfo.cgi/barracuda
FAQ - http://www.jguru.com/faq/Barracuda