Hi Sean, Shravan Kumar wrote:
> Thanks Joe. Looking forward to a fix. > > Let me know if you need any additional info. You're absolutely right, getting the cached element not required to be synched here. Can you open a JIRA issue please, just to track the change? It's different from XSTR-635, since at that time the cache was realized with a (non-working) WeakHashMap. - Jörg > > 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 >>>> >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
