[jbosscache-dev] Re: new utility classes for removing Thread.sleeps

[Manik Surtani]

Looks good.  A couple of implementation notes:

1.  ReplicationListener constructor - getting components from the cache

TestingUtil.extractField() is brittle (since it relies on field name)  
and could break with even the slightest refactoring.  Better to use  
TestingUtil.extractComponentRegistry() and  
ComponentRegistry.getComponent() to get the component you want.  Much  
safer.

2.  ReplicationListener constructor - updating components in the cache

Again rather than using TestingUtil.replaceField() - equally brittle -  
try using componentRegistry.registerComponent() to register a new  
component, and componentRegistry.rewire() if the cache is already  
running to ensure the new component is re-injected everywhere it is  
needed.

3.  How does this behave with sync replication?  The javadocs say it  
doesn't make any sense, but it may be done in base test classes, such  
that the test could have subclasses which use sync and async  
replication.  I'm guessing waitForReplication() will always return  
immediately with sync replication?

Cheers,
Manik

PS: cc'ing jbosscache-dev - discussions like this should be on the  
list, just in case anyone else is interested.  :-)




On 29 May 2008, at 08:41, Mircea Markus wrote:

> I've just migrated o.j.c.replicated.AsyncReplTest  to the new  
> listener mechanism.
> Can you please take a look and let me know what do you think.
>
> Cheers,
> Mircea
>
> Brian Stansberry wrote:
>> Try o.j.c.replicated.AsyncReplTest
>>
>> Mircea Markus wrote:
>>> Sorry, wrong button :)
>>> Can you point me to such a class? I'll continue refactoring on Th  
>>> and I'll start with one of these for convenience. The plan is to  
>>> remove (almost) all 'sleeps' from code.
>>>
>>> Mircea Markus wrote:
>>>> Can you point me
>>>>
>>>> Brian Stansberry wrote:
>>>>> Thanks. Are you planning to add one for the ordinary REPL_ASYNC  
>>>>> case; i.e. no replication queue?  That's the one where I end up  
>>>>> adding Thread.sleep() the most -- waiting to ensure the async  
>>>>> message has arrived on the remote node before testing failover.
>>>>>
>>>>> Mircea Markus wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Take a look at  
>>>>>> org.jboss.cache.util.internals.EvictionController and  
>>>>>> org.jboss.cache.util.internals.ReplicationQueueNotifier.
>>>>>> Right now they are only being used in  
>>>>>> StateTransferConcurrencyTest, I will change more tests to use  
>>>>>> them later on this week. Any feedback is welcomed!
>>>>>> Cheers,
>>>>>> Mircea
>>>>>
>>

--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org