JVM stalls due to StringConverter when using a single long running instance of XStream

Opps - let me just correct two mistakes that I made above.

1) It was discussed in XSTR-410 rather than the original XSTR-395.

2) An OOME might not actually happen... but the JVM will grind to a halt and spend most of it's time doing FULL GC's.

Well, the point is that you may actually create OOMEs with the non-caching version, because in scenarios with enum like values each string is an own instance although in the original object graph these instances have been shared i.e. the application is no longer able to keep the same amount of object graphs in memory when they have been deserialized. It's difficult to say wether switching-off the cache as default will raise more problems. Basically the cache of the StringConverter will increase the problem in low memory situations, but the question is, if this low memory situation is caused by a complete different bug in the software using XStream that eats up the memory over time.

Thanks for the speedy update.

In my situation, I have a 2GB heap and with the caching converter the heap steadily fills up at which point the GC kicks in and clears a bit of space, but the throughput of serialised objects is high and means that the GC doesn't clear enough compared to new strings being cached. The application enters a state whereby the GC is constantly thrashing and the application stops handling requests properly.

Maybe the solution is to properly document both of these situations and provide an easy switch to Non caching?

Did you actually try a non-cached version? I wonder, if the heap is filled also.

Yes, my app has been running in production now for 4 days (with a non-caching StringConverter installed) and the heap is correctly growing and shrinking back down with occasional Full GC's. With the default caching version the heap would just continue growing until it entered the churning state.

Interesting. To get a better understanding of the use case and what I should document: I assume you're using a singleton instance of the XStream. Do you have multiple threads with ongoing deserialization tasks of smaller XML chunks or do you use the deserialization from time to time with "mass" data?

This particular application is a centralised logging and auditing system. So the server has a thin servlet layer which simply accepts HTTP POSTed uploads and then uses an XStream singleton configured like this:

private static XStream createJsonXStream()
{
XStream result = new XStream(new JettisonMappedXmlDriver());
result.setMode(XStream.NO_REFERENCES);
result.alias("item", GenericAuditItem.class);
result.registerConverter( timestampConverter );
result.registerConverter(new NonCachingStringConverter());
return result;
}

to convert the JSON messages into AuditItem instances before inserting them into a MySQL database. There is a high throughput of potentially multi-megabytes per second. Perhaps this is an unusual use for XStream?

So to answer your questions: I have multiple threads (each http post handler thread) deserialising large quantities of data all the time!

What I would have been interested additionally is a feeling for the provided XML data at a single deserialization call. In my profiling cases the cached StringConversion version was always better than an uncached implementation. Now, if the deserialized object graph is rather small (compared to the available memory) you might change the implementation to use a cache per (de)serialization context. In this case you would not even have to use a WeakHashMap - a normal one will do. You can lookup the map in the provided context under a predefined key and create a normal HashMap if it is not available yet. Since the context is not shared and only used for a single (de)serialization task, there's no need for synchronization or further cleanup. The only drawback is that this converter can only be implemented as "normal" converter and it is not possible to use it for Strings that are represented as attributes. However, if you try such a solution, you should actually profile the effect to get real numbers.

I don't see any benefit for me for caching strings during deserialisation. My data is always going to be different for each deserialisation and I'm expecting it all to be extremely short lived. Http POST RQ --> JSON body --> Object --> DB Insert --> Http RS --> All objects permitted to be Garbage Collected (total time about 10 to 40ms).

Hi, I'd like to raise this issue as well, we found this problem in the late stages of perf testing and I think that this should be an option that is off by default. I don't see why this code exists, and Java's String.intern() is not used, intern() has support garbage collection. Clearly it should be an option to turn this off, since this code and String.intern() use sync blocks, and in our use cases synchronization is almost always more expensive than creating new objects. Lots of concurrent web server threads, I think this is a fairly normal case.

We have the exact same use case as Adam, we don't want XStream caching Strings that should have a short life time and be garbage collected quickly and definatly String handling which is core and used regularly should not involve sync locking.

"I don't see any benefit for me for caching strings during deserialisation. My data is always going to be different for each deserialisation and I'm expecting it all to be extremely short lived. Http POST RQ --> JSON body --> Object --> DB Insert --> Http RS --> All objects permitted to be Garbage Collected (total time about 10 to 40ms)."

I don't see why this code exists, and Java's String.intern() is not used, intern() has support garbage collection.

You should really read allthis stuff about this issue then you would know where we came from.
http://www.codeinstructions.com/2009/01/busting-javalangstringintern-myths.html

Hi,

I am using XStream version 1.3.1. Still I faced this problem of java.lang.OutOfMemoryError: PermGen space. Has this issue been resolved completely or does this still persist.

Few lines of exception:
Exception in thread "DemandGen-JobStatusPollerThread" java.lang.OutOfMemoryError: PermGen space
at java.lang.String.intern(Native Method)
at com.thoughtworks.xstream.converters.basic.StringConverter.fromString (StringConverter.java:19)

I am creating single instance of XStream which is being used for long and my use case relates to different strings each time, thus caching is not at all important.

Would using non caching version of StringConverter or creating new instance of XStream solve this problem ?

Thanks

@Jitendra: You're definitely not using XStream 1.3.1. However, the user's list is the appropriate place for discussion.

Hi,
I was wandering where can I find NonCachingStringConverter ? Do I need to write it on my own?

@Bartosz: Currently, yes. It's more that trivial.

The StringConverter has a constructor taking a map that can be used for the cache. Upcoming XStream version will support a null value as parameter value to turn off the cache completely.