JBoss Cache, JGroups and TestNG

Looking at using the thread counts and parallelizing test
execution in  
TestNG (as Bela has done with JGroups), one of my biggest
stumbling  
blocks is that quite a few tests end up starting and
stopping  
replicated JBoss Cache instances.  If these tests were to be
run in  
parallel, they would detect each other and produce
unexpected results.

Question for any of the JGroups guys on this list: how did
you get  
around this with creating JGroups channels, as I expect you
have the  
same problem?  Or do you not run tests that create/start
channels in  
parallel?

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Manik Surtani wrote:
> Looking at using the thread counts and parallelizing
test execution in 
> TestNG (as Bela has done with JGroups), one of my
biggest stumbling 
> blocks is that quite a few tests end up starting and
stopping 
> replicated JBoss Cache instances.  If these tests were
to be run in 
> parallel, they would detect each other and produce
unexpected results.
>
> Question for any of the JGroups guys on this list: how
did you get 
> around this with creating JGroups channels, as I expect
you have the 
> same problem?  Or do you not run tests that
create/start channels in 
> parallel?

I haven't done this yet, but the idea is to change
ChannelTestBase 
(superclass for all stack-dependent tests) to use a resource
pool which 
manages multicast addresses and multicast ports (or TCP
ports): each 
test removes a multicast address:port combo and returns it
when done. 
Same for TCP ports.

Once we have a valid multicast address/port, the superclass
will modify 
the transport properties *before* the channel is started.

I'll keep you posted when I'm done implementing this (should
be end of 
next week).

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Cool, sounds interesting.


On 27 Mar 2008, at 16:24, Bela Ban wrote:
>
>
> Manik Surtani wrote:
>> Looking at using the thread counts and
parallelizing test execution  
>> in TestNG (as Bela has done with JGroups), one of
my biggest  
>> stumbling blocks is that quite a few tests end up
starting and  
>> stopping replicated JBoss Cache instances.  If
these tests were to  
>> be run in parallel, they would detect each other
and produce  
>> unexpected results.
>>
>> Question for any of the JGroups guys on this list:
how did you get  
>> around this with creating JGroups channels, as I
expect you have  
>> the same problem?  Or do you not run tests that
create/start  
>> channels in parallel?
>
> I haven't done this yet, but the idea is to change
ChannelTestBase  
> (superclass for all stack-dependent tests) to use a
resource pool  
> which manages multicast addresses and multicast ports
(or TCP  
> ports): each test removes a multicast address:port
combo and returns  
> it when done. Same for TCP ports.
>
> Once we have a valid multicast address/port, the
superclass will  
> modify the transport properties *before* the channel is
started.
>
> I'll keep you posted when I'm done implementing this
(should be end  
> of next week).
>
> -- 
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss - a division of Red Hat

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev