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