I've just filed the jira issue, with attached patch: https://jira.terracotta.org/jira/browse/FORGE-572
On Tue, Jan 12, 2010 at 7:30 PM, Chris Dennis <cden...@terracottatech.com> wrote: > Assuming you mean the change that you inlined in your email a while back, > then yes that seems fine. > > Chris > > On Jan 12, 2010, at 1:18 PM, Sergio Bossa wrote: > >> Got it. >> So what about the fix above? >> It seems the correct way to handle that do you confirm? >> >> Sergio Bossa >> Sent by iPhone >> >> Il giorno 12/gen/2010, alle ore 18.55, Chris Dennis >> <cden...@terracottatech.com> ha scritto: >> >>> As I understand it prefetch dirtily reads the value and if its an >>> ObjectID it asks the server to start the lookup process. This means once we >>> have actually locked the key and do the real request to the server (if its >>> required - since we did do the original read dirtily the ObjectID might have >>> been a stale value) then the server will already have the answer waiting for >>> us. >>> >>> Chris >>> >>> On Jan 12, 2010, at 12:51 PM, Steve Harris wrote: >>> >>>> I'll have to double check but my understanding is that prefetch kicks >>>> off a lookup and returns >>>> what is local. I think it's a way to parallelize things a bit. So the >>>> null would mean that it just hasn't >>>> shown up yet if I'm correct. >>>> >>>> On Jan 12, 2010, at 9:45 AM, Sergio Bossa wrote: >>>> >>>>> Thanks Chris, Steve. >>>>> >>>>> That did the trick: I reproduced the problem and verified the fix >>>>> (reported previously in this thread). >>>>> >>>>> Anyways, there are still a few questions: in particular, does >>>>> prefetch() return null because the mapping doesn't actually exist in >>>>> the master server? >>>>> >>>>> This means that, if the fix only works because it delays the moment it >>>>> loads the mapping, the original code is indeed correct: then the >>>>> problem may be the *async write toward the master*, taking too long. >>>>> >>>>> To verify that, let me check with sync writes enabled .... come back >>>>> in a few minutes. >>>>> >>>>> On Tue, Jan 12, 2010 at 6:26 PM, Chris Dennis >>>>> <cden...@terracottatech.com> wrote: >>>>>> >>>>>> Sergio, >>>>>> >>>>>> I just put a Thread.sleep in the __tc_applicator_put method of >>>>>> ConcurrentDistributedMapDso that way you can delay the application of >>>>>> new >>>>>> puts, and make the race to perform an incoherent read of a locally >>>>>> non-existent mapping much wider. Its not something you can do >>>>>> permanently, >>>>>> but it can be used to at least verify the fix. >>>>>> >>>>>> Chris >>>>>> >>>>>> On Jan 12, 2010, at 12:21 PM, Steve Harris wrote: >>>>>> >>>>>>> chris used a trick in another test to slow down broadcast applys to >>>>>>> exacerbate an issue. Maybe he can tell you how he did that? >>>>>>> >>>>>>> On Jan 12, 2010, at 9:09 AM, Sergio Bossa wrote: >>>>>>> >>>>>>>> Okay, now I'm *sure* that ConcurrentDistributedMapDso#prefetch() >>>>>>>> actually returns null even if the mapping is existent (confirmed by >>>>>>>> logging sessions). >>>>>>>> Too bad, while that always happen in my application, I'm unable to >>>>>>>> reproduce the same case through a system test. >>>>>>>> >>>>>>>> I'll keep trying and keep you posted. >>>>>>>> >>>>>>>> On Tue, Jan 12, 2010 at 4:20 PM, Steve Harris >>>>>>>> <st...@terracottatech.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Could someone create a test for the bug too. >>>>>>>>> >>>>>>>>> On Jan 12, 2010, at 7:15 AM, Jason Voegele wrote: >>>>>>>>> >>>>>>>>>> On Tue, 2010-01-12 at 15:40 +0100, Sergio Bossa wrote: >>>>>>>>>>> >>>>>>>>>>> Do you want me to file a jira issue and commit the fix (I have >>>>>>>>>>> commit >>>>>>>>>>> access to the forge), or do you want to fix it by yourself? >>>>>>>>>>> Moreover, is it possible to issue a new module release as soon as >>>>>>>>>>> the >>>>>>>>>>> bug is fixed (which is why I'm adding Jason to the thread)? >>>>>>>>>> >>>>>>>>>> I'll be happy to cut a new release when you and Chris think it is >>>>>>>>>> ready. >>>>>>>>>> Just post a message with the request when ready. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jason Voegele >>>>>>>>>> Remembering is for those who have forgotten. >>>>>>>>>> -- Chinese proverb >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> tc-dev mailing list >>>>>>>>>> tc-dev@lists.terracotta.org >>>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sergio Bossa >>>>>>>> Software Passionate and Open Source Enthusiast. >>>>>>>> URL: http://www.linkedin.com/in/sergiob >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sergio Bossa >>>>> Software Passionate and Open Source Enthusiast. >>>>> URL: http://www.linkedin.com/in/sergiob >>>> >>> > > -- Sergio Bossa Software Passionate and Open Source Enthusiast. URL: http://www.linkedin.com/in/sergiob _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
