Okay, the sync write lock doesn't fix the problem by itself (so it shouldn't be an async communication problem).
The "not null" fix instead solves the problem, even with long delays in the __tc_applicator_put method and async write locks. So I'd say it's the definite fix to the problem. Thoughts? On Tue, Jan 12, 2010 at 6:51 PM, Steve Harris <st...@terracottatech.com> 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
