[
https://issues.apache.org/jira/browse/SHINDIG-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790267#comment-13790267
]
Stanton Sievers commented on SHINDIG-1935:
------------------------------------------
I don't think there's anything you can really do given what is currently being
cached. Because TemplateLibraryFactory is caching Element, we can't straight
out ignore Element. We would need insight into the Element implementation
which is a bad smell.
Taking a step back, I think the better solution may be to change what
TemplateLibraryFactory is caching. Today the TemplateLibraryFactory caches an
Element, which is simply the result of an XML parse of the response from the
request for the template. That's all well and good, but it immediately turns
around and creates the actual TemplateLibrary from that content. Why not cache
the TemplateLibrary, which does further processing on the Element? And because
we own XmlTemplateLibrary (the only implementation of TemplateLibrary), we have
a much better chance of ignoring content in the object graph that shouldn't
count towards the size of the object in the cache. Btw, looking at
XmlTemplateLibrary, it doesn't appear to store any complex objects that would
blow up its object graph.
To Henry's point, I'd rather not get into a pattern of using one-off caches
that aren't provided by CacheProvider for these types of cases. If we run into
a problem like this that can't be resolved using the standard EhCache
implementation, I think we should look at improving our the EhCache
implementation.
> Add org.apache.xerces.dom.DeferredElementNSImpl to sizeoffilter.txt to have
> EH Cache ignore this class
> ------------------------------------------------------------------------------------------------------
>
> Key: SHINDIG-1935
> URL: https://issues.apache.org/jira/browse/SHINDIG-1935
> Project: Shindig
> Issue Type: Bug
> Affects Versions: 2.5.0, 2.5.1, 2.5.0-update1
> Reporter: Ryan Baxter
> Assignee: Ryan Baxter
> Attachments: org.apache.xerces.dom.DeferredElementNSImpl.txt
>
>
> When rendering a gadget I am seeing a warning from EH Cache saying it had
> exceeded the 1000 object limit when traversing the object graph. After
> enabling additional EH Cache logging it looks like the class
> org.apache.xerces.dom.DeferredElementNSImpl has a pretty big object graph. I
> believe this class is used to represent DOM elements so it could be that the
> HTML for the gadget is fairly large making the object graph representing one
> of the elements pretty large as well. I think it is safe to ignore this
> class since classing the Java Object representation of the HTML is not as
> important as caching the HTML itself. I have attached the EH Cache debug
> with the details of the object graph.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
