Thanks Joe. Looking forward to a fix. Let me know if you need any additional info.
Sean On Tue, Sep 4, 2012 at 11:16 AM, Joe Walnes <[email protected]> wrote: > 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 >>> >>> >>> >> >
