[
https://issues.apache.org/jira/browse/SHINDIG-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822195#comment-13822195
]
Yun Zhi Lin commented on SHINDIG-1935:
--------------------------------------
By enabling the DEBUG level log in
net.sf.ehcache.pool.sizeof.ObjectGraphWalker, we can see lots of String objects
visited when ehcache calculates the size of the parsed xml . It appears each
line in the Javascript CDATA section generates a String , and two objects will
be counted (the String and its char array) . The default sizeOf policy sets
the maxDepth to 1000, which means if the javascript code in the template
reaches around 500 lines, this warning will be thrown.
The javascript in template can be complex . 500 lines may not be enough. We
have specific sizeof policy setting for FeatureJSCache, increasing the
maxDepth to 5000. I think it makes sense to use a specific cache setting for
template cache as well.
Another option is to cache a processed xml file instead of the original one,
for example, compact the js code in template or simply remove all new lines in
the js. This helps to reduce the string object number. This would most likely
effect the readability of the code sent to the browser. But when we enable the
cache , we are most likely in a production environment. Or maybe we can
provide an option to configure whether we will compact the js before caching
the template .
> 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)
