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
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
