I think I see what's happening here. The fix for http://jira.codehaus.org/browse/XSTR-635 puts the cache read inside the synchronization block: https://fisheye.codehaus.org/changelog/xstream?cs=1775. This is better than before, as it eliminates the possible race condition of a bad read. However, it introduces contention, forcing all concurrent threads to enter the same synchronization block, even if the field results are already cached.
I believe a slight improvement would be to perforrm a fast unsyncronized read first, then fall back to the synchronized for the safe check. However, I'd rather discuss this with Jörg when he gets back from vacation before making any changes. -Joe On Tue, Sep 4, 2012 at 7:53 AM, Shravan Kumar <[email protected]> wrote: > The code is running in WebSphere (6.1) using IBM Java 1.5. Use case is to > serialize session data and store it. > Dynatrace dumps show that some requests are taking long time and the > synchronous code in buildMap method of FieldDictionary seems to be the > culprit. > > Sean > > On Tue, Sep 4, 2012 at 12:14 AM, Paul Hammant <[email protected]> wrote: > >> Can you describe your production(?) run scenario a little more ? >> >> - Paul >> >> On Mon, Sep 3, 2012 at 8:48 PM, Shravan K Pabba <[email protected]> >> wrote: >> > Hi Paul >> > >> > Thanks for the pointer. I am using 1.4.2 which should have these fixes. >> > >> > Sent from my iPhone >> > >> > On Sep 3, 2012, at 11:07 PM, Paul Hammant <[email protected]> wrote: >> > >> >> Sean, >> >> >> >> http://jira.codehaus.org/browse/XSTR-636 and >> >> http://jira.codehaus.org/browse/XSTR-635 fixed concurrency issues for >> >> FieldDictionary, are you sure you're using the latest XStream release >> >> ??? >> >> >> >> - Paul >> >> >> >> On Mon, Sep 3, 2012 at 7:13 PM, Shravan Kumar <[email protected]> >> wrote: >> >>> Hi, >> >>> I am using XStream as part of my application for serializing >> >>> classes. For one of the use cases, I have to serialize some of the >> classes >> >>> implementing Externalizable interface. For my use case I would like to >> >>> serialize them using native Java serialization. I found a link on the >> >>> internet, >> >>> >> http://old.nabble.com/How-to-remove-Externalizable-Converter-td22747484.html >> , >> >>> which helped me address this issue and started using Reflection >> Converter >> >>> for my Externalizable classes. >> >>> >> >>> When testing the application, I am seeing that the application is >> spending >> >>> lot of time in converter code during highly concurrent access. I can >> see >> >>> that the problem is in the buildMap method of FieldDictionary, >> >>> >> http://svn.codehaus.org/xstream/trunk/xstream/src/java/com/thoughtworks/xstream/converters/reflection/FieldDictionary.java >> >>> >> >>> I was wondering if there is a better way to address my original >> issue? Is >> >>> the performance for Reflection Converter expected to be bad when >> having >> >>> highly concurrent environment? >> >>> >> >>> I really appreciate any help/advice regarding this. Thanks for the >> help >> >>> >> >>> Regards >> >>> Shravan (Sean) Pabba >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe from this list, please visit: >> >> >> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this list, please visit: >> > >> > http://xircles.codehaus.org/manage_email >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
