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
> <[email protected]> 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 <[email protected]>
>>>> 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
>>>>>> [email protected]
>>>>>> 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

_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev

Reply via email to