Thursday, July 7, 2011

OSB, side effects of caching Xqueries

One instance of "com.bea.wli.config.derivedcache.DerivedCache" loaded by "sun.misc.Launcher$AppClassLoader @ 0x7812ef450" occupies 1,090,992,792 (72.62%) bytes. The memory is accumulated in one instance of "weblogic.xml.query.xdbcimpl.XQueryPreparedStatementImpl" loaded by "sun.misc.Launcher$AppClassLoader @ 0x7812ef450".

apparently, OSB internally "precompiles" and caches XQuery, which sound pretty reasonable for performance issues.

The side effect is that, if your XQuery is nothing but a huge XML, the format by which this XML is saved in memory is very inefficient.

Our XQuery was simply returning a 10k elements XML, each element being 1K, so a total of 10M on file.

This XQuery ends up taking 1GB of memory, and the performance of my server drops dramatically because very less RAM is available afterwards.

If took a heap dump and Eclipse MAT to discover that.

I think in future we will do a Java Callout returning the content of a file, and converting it to XmlObject with fn-bea:inlinedXML() - that should not put anything in a Cache!

updates: in the custom XPath I read a xml file (. path is relative to user.dir = domain home), using XmlObject.parse(File), and returing XmlObject to OSB.... it works very well without any caching side effect.

This inspires me an interesting pattern: in my Mock Service, I use the unique ID of the request to identify a specific XML file on disk (eg id=408 retrieves file train408.xml). This will enable us to easily serve different data for different IDs.

No comments: