Hi Mike, in a recent Pebble ML exchange w/ James et. al. I got some
feedback about implementing twitter4j in Pebble.
I can only +1 your intentions and hope your changes find their way back
to the repo.
BTW: the Pebble repo is much better now that it is in github thanks to
James.
A gitflow clone of the Pebble repo makes working on issues very easy and
safe.
HTH, David.
On 01/08/2013 12:09 PM, Mike Bremford wrote:
Hi all
I've been suffering a slow leak on my site for months and have finally got
annoyed enough to try and track it down. It's proving tricky but I think
it's coming from Pebble, specifically the ContentDecorator.
I'm using the SuffixDecorator (which I wrote, coincidentally, but it's not
specific to this class). This modifies the BlogEntry body by calling
BlogEntry.setBody(), which is the normal way of doing things (see
https://github.com/pebbleblog/pebble/blob/master/src/main/java/net/sourceforge/pebble/decorator/RelativeUriDecorator.java
).
This call to BlogEntry.setBody() fires a PropertyChangeEvent which is
stored in the propertyChangeEvents list in
the net.sourceforge.pebble.domain.Content superclass. However I don't think
that list is being cleared.
It looks to me like it's only cleared when the entry is committed to disk,
but this is a temporary change for display only (to that end I'd query why
a PropertyChange event needs to be fired at all, let alone saved, in this
case).
I'm not 100% sure of this as the traces are necessarily incomplete (this is
on our live site, so I can't trash it by profiling too much). However I
have PropertyChangeEvents that are (a) strongly referenced from only the
propertyChangeEvents list, (b) indicate the "body" property was changed,
(c) that come from a Decorator, not a permanent change (because I didn't
make any) and (d) that are very old. The only place I can find in the
codebase these would be generated is PageBasedContent.setBody().
We have a few articles with maybe 12KB of text - every page view fires this
event, the events stores the old and new values of the body (24KB) and
eventually it adds up and our JVM has to be restarted.
To resolve - well I'm not very familiar with the internals of pebble, but
I'd expect we're decorating a clone of the original BlogEntry rather than
the entry itself? In that case somehow marking this as a transient item
with no need to fire or store PropertyChangeEvents would be the best
solution. But I'm sure James or someone more familiar with the guts will
have a better idea.
Cheers... Mike
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Pebble-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pebble-user
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Pebble-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pebble-user