InVM Dispatcher etc... - backend TestHarness

[Jules Gosnell-4]

Gianny,

I've been rationalising the tests a bit more - coverage slowly rising :-)

I have introduced a new test suite that can be run against our backends :

./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java

In the dispatcher module, this test is written against the InVM impl.
In the other backends it is subclassed and the InVM impl is replaced
with the relevant backend.
I hope to increase the number of tests in it, until we have a pretty
good test harness for any new backend - e.g. Tribes

It runs fine against AC and JG at the moment, but is not so happy with
InVM :-(

Would you mind taking a look, when you have time,

Cheers :-)


Jules

P.S.

Gianni and Filip,

you may want to consider putting Tribes underneath this as a first test
of the new backend...

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Gianny,

My bad !

I've just taken a look at this - I had added an implementation of
'waitForClusterToStart' - but on the shared rather than local Cluster -
so it didn't work, because all the peers are remote to the shared one...
- fixed that.
Ensured that setAddress(target) was called on outgoing messages as the
test uses this.
just looking at ensuring object identity for Addresses - so the same
Address is always '==' instead of just 'equals()' - WADI doesn't yet
need it, but I putting it into all backends so that we can soon use this
feature to avoid getting multiple views on a remote Peer in the same
local Peer.

Jules

>
> I've been rationalising the tests a bit more - coverage slowly rising :-)
>
> I have introduced a new test suite that can be run against our backends :
>
> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>
>
> In the dispatcher module, this test is written against the InVM impl.
> In the other backends it is subclassed and the InVM impl is replaced
> with the relevant backend.
> I hope to increase the number of tests in it, until we have a pretty
> good test harness for any new backend - e.g. Tribes
>
> It runs fine against AC and JG at the moment, but is not so happy with
> InVM :-(
>
> Would you mind taking a look, when you have time,
>
> Cheers :-)
>
>
> Jules
>
> P.S.
>
> Gianni and Filip,
>
> you may want to consider putting Tribes underneath this as a first
> test of the new backend...
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Gianny Damour-2]

Hi Jules,

TestGroup is now passing on my local version. If you wait a little bit,
I will commit my updates.

Also, TestGroup does not pass with the AC backend on my box. Could you
please confirm that it works on my machine? This is the reason why I
have not yet checked in my local updates...

Thanks,
Gianny

Jules Gosnell wrote:

> Jules Gosnell wrote:
>
>> Gianny,
>
>
> My bad !
>
> I've just taken a look at this - I had added an implementation of
> 'waitForClusterToStart' - but on the shared rather than local Cluster
> - so it didn't work, because all the peers are remote to the shared
> one... - fixed that.
> Ensured that setAddress(target) was called on outgoing messages as the
> test uses this.
> just looking at ensuring object identity for Addresses - so the same
> Address is always '==' instead of just 'equals()' - WADI doesn't yet
> need it, but I putting it into all backends so that we can soon use
> this feature to avoid getting multiple views on a remote Peer in the
> same local Peer.
>
> Jules
>
>>
>> I've been rationalising the tests a bit more - coverage slowly rising
>> :-)
>>
>> I have introduced a new test suite that can be run against our
>> backends :
>>
>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>
>>
>> In the dispatcher module, this test is written against the InVM impl.
>> In the other backends it is subclassed and the InVM impl is replaced
>> with the relevant backend.
>> I hope to increase the number of tests in it, until we have a pretty
>> good test harness for any new backend - e.g. Tribes
>>
>> It runs fine against AC and JG at the moment, but is not so happy
>> with InVM :-(
>>
>> Would you mind taking a look, when you have time,
>>
>> Cheers :-)
>>
>>
>> Jules
>>
>> P.S.
>>
>> Gianni and Filip,
>>
>> you may want to consider putting Tribes underneath this as a first
>> test of the new backend...
>>
>
>

[Jules Gosnell-4]

Gianny Damour wrote:

> Hi Jules,
>
> TestGroup is now passing on my local version. If you wait a little
> bit, I will commit my updates.

Cool.

So have you made the same changes as I have made ?

Jules

>
> Also, TestGroup does not pass with the AC backend on my box. Could you
> please confirm that it works on my machine? This is the reason why I
> have not yet checked in my local updates...
>
> Thanks,
> Gianny
>
> Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny,
>>
>>
>>
>> My bad !
>>
>> I've just taken a look at this - I had added an implementation of
>> 'waitForClusterToStart' - but on the shared rather than local Cluster
>> - so it didn't work, because all the peers are remote to the shared
>> one... - fixed that.
>> Ensured that setAddress(target) was called on outgoing messages as
>> the test uses this.
>> just looking at ensuring object identity for Addresses - so the same
>> Address is always '==' instead of just 'equals()' - WADI doesn't yet
>> need it, but I putting it into all backends so that we can soon use
>> this feature to avoid getting multiple views on a remote Peer in the
>> same local Peer.
>>
>> Jules
>>
>>>
>>> I've been rationalising the tests a bit more - coverage slowly
>>> rising :-)
>>>
>>> I have introduced a new test suite that can be run against our
>>> backends :
>>>
>>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>>
>>>
>>> In the dispatcher module, this test is written against the InVM impl.
>>> In the other backends it is subclassed and the InVM impl is replaced
>>> with the relevant backend.
>>> I hope to increase the number of tests in it, until we have a pretty
>>> good test harness for any new backend - e.g. Tribes
>>>
>>> It runs fine against AC and JG at the moment, but is not so happy
>>> with InVM :-(
>>>
>>> Would you mind taking a look, when you have time,
>>>
>>> Cheers :-)
>>>
>>>
>>> Jules
>>>
>>> P.S.
>>>
>>> Gianni and Filip,
>>>
>>> you may want to consider putting Tribes underneath this as a first
>>> test of the new backend...
>>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Gianny Damour wrote:

> Hi Jules,
>
> TestGroup is now passing on my local version. If you wait a little
> bit, I will commit my updates.
>
> Also, TestGroup does not pass with the AC backend on my box. Could you
> please confirm that it works on my machine? This is the reason why I
> have not yet checked in my local updates...
>
The AC TestGroup works fine on my box, and (was working) on the
Beetlejuice host - what OS are you running ?

BTW - A couple of my InVM tests fail and at least one passes, but throws
exceptions that it should not. As soon as we have InVM TestGroup
working, i will turn my attention to these, probably pusing more tests
into TestGroup, until we have them all working reliably... I'll keep you
posted.

Jules

> Thanks,
> Gianny
>
> Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny,
>>
>>
>>
>> My bad !
>>
>> I've just taken a look at this - I had added an implementation of
>> 'waitForClusterToStart' - but on the shared rather than local Cluster
>> - so it didn't work, because all the peers are remote to the shared
>> one... - fixed that.
>> Ensured that setAddress(target) was called on outgoing messages as
>> the test uses this.
>> just looking at ensuring object identity for Addresses - so the same
>> Address is always '==' instead of just 'equals()' - WADI doesn't yet
>> need it, but I putting it into all backends so that we can soon use
>> this feature to avoid getting multiple views on a remote Peer in the
>> same local Peer.
>>
>> Jules
>>
>>>
>>> I've been rationalising the tests a bit more - coverage slowly
>>> rising :-)
>>>
>>> I have introduced a new test suite that can be run against our
>>> backends :
>>>
>>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>>
>>>
>>> In the dispatcher module, this test is written against the InVM impl.
>>> In the other backends it is subclassed and the InVM impl is replaced
>>> with the relevant backend.
>>> I hope to increase the number of tests in it, until we have a pretty
>>> good test harness for any new backend - e.g. Tribes
>>>
>>> It runs fine against AC and JG at the moment, but is not so happy
>>> with InVM :-(
>>>
>>> Would you mind taking a look, when you have time,
>>>
>>> Cheers :-)
>>>
>>>
>>> Jules
>>>
>>> P.S.
>>>
>>> Gianni and Filip,
>>>
>>> you may want to consider putting Tribes underneath this as a first
>>> test of the new backend...
>>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Gianny Damour-2]

Jules Gosnell wrote:

> Gianny Damour wrote:
>
>> Hi Jules,
>>
>> TestGroup is now passing on my local version. If you wait a little
>> bit, I will commit my updates.
>
>
> Cool.
>
> So have you made the same changes as I have made ?

Same changes + what is required to be able to use "==" instead of
"equals" on Address.

Thanks,
Gianny

>
> Jules
>
>>
>> Also, TestGroup does not pass with the AC backend on my box. Could
>> you please confirm that it works on my machine? This is the reason
>> why I have not yet checked in my local updates...
>>
>> Thanks,
>> Gianny
>>
>> Jules Gosnell wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny,
>>>
>>>
>>>
>>>
>>> My bad !
>>>
>>> I've just taken a look at this - I had added an implementation of
>>> 'waitForClusterToStart' - but on the shared rather than local
>>> Cluster - so it didn't work, because all the peers are remote to the
>>> shared one... - fixed that.
>>> Ensured that setAddress(target) was called on outgoing messages as
>>> the test uses this.
>>> just looking at ensuring object identity for Addresses - so the same
>>> Address is always '==' instead of just 'equals()' - WADI doesn't yet
>>> need it, but I putting it into all backends so that we can soon use
>>> this feature to avoid getting multiple views on a remote Peer in the
>>> same local Peer.
>>>
>>> Jules
>>>
>>>>
>>>> I've been rationalising the tests a bit more - coverage slowly
>>>> rising :-)
>>>>
>>>> I have introduced a new test suite that can be run against our
>>>> backends :
>>>>
>>>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>>>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>>>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>>>
>>>>
>>>> In the dispatcher module, this test is written against the InVM impl.
>>>> In the other backends it is subclassed and the InVM impl is
>>>> replaced with the relevant backend.
>>>> I hope to increase the number of tests in it, until we have a
>>>> pretty good test harness for any new backend - e.g. Tribes
>>>>
>>>> It runs fine against AC and JG at the moment, but is not so happy
>>>> with InVM :-(
>>>>
>>>> Would you mind taking a look, when you have time,
>>>>
>>>> Cheers :-)
>>>>
>>>>
>>>> Jules
>>>>
>>>> P.S.
>>>>
>>>> Gianni and Filip,
>>>>
>>>> you may want to consider putting Tribes underneath this as a first
>>>> test of the new backend...
>>>>
>>>
>>>
>>
>>
>
>

[Jules Gosnell-4]

Gianny Damour wrote:

> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Hi Jules,
>>>
>>> TestGroup is now passing on my local version. If you wait a little
>>> bit, I will commit my updates.
>>
>>
>>
>> Cool.
>>
>> So have you made the same changes as I have made ?
>
>
> Same changes + what is required to be able to use "==" instead of
> "equals" on Address.

great :-)

FYI - here is a breakdown of the borken (my side) InVM tests :

        <exclude
implementation="java.lang.String">**/TestInVMReplicationContextualiser.java</exclude><!--
runs but throws exception -->
        <exclude
implementation="java.lang.String">**/TestInVMEvacuation.java</exclude><!--
runs but wong -->
        <exclude
implementation="java.lang.String">**/TestInVMRelocation.java</exclude><!--
runs but wong -->

'runs but wrong' - means that whilst the test succeeds, I can tell from
the output that not everything went to plan. In both cases something
goes wrong with Partition negotiation and multiple copies of the same
Partition arise and have to be resolved...

I will start looking at this as soon as you get checked in.

thanks,

Jules

>
> Thanks,
> Gianny
>
>>
>> Jules
>>
>>>
>>> Also, TestGroup does not pass with the AC backend on my box. Could
>>> you please confirm that it works on my machine? This is the reason
>>> why I have not yet checked in my local updates...
>>>
>>> Thanks,
>>> Gianny
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Gianny,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> My bad !
>>>>
>>>> I've just taken a look at this - I had added an implementation of
>>>> 'waitForClusterToStart' - but on the shared rather than local
>>>> Cluster - so it didn't work, because all the peers are remote to
>>>> the shared one... - fixed that.
>>>> Ensured that setAddress(target) was called on outgoing messages as
>>>> the test uses this.
>>>> just looking at ensuring object identity for Addresses - so the
>>>> same Address is always '==' instead of just 'equals()' - WADI
>>>> doesn't yet need it, but I putting it into all backends so that we
>>>> can soon use this feature to avoid getting multiple views on a
>>>> remote Peer in the same local Peer.
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> I've been rationalising the tests a bit more - coverage slowly
>>>>> rising :-)
>>>>>
>>>>> I have introduced a new test suite that can be run against our
>>>>> backends :
>>>>>
>>>>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>>>>>
>>>>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>>>>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>>>>
>>>>>
>>>>> In the dispatcher module, this test is written against the InVM impl.
>>>>> In the other backends it is subclassed and the InVM impl is
>>>>> replaced with the relevant backend.
>>>>> I hope to increase the number of tests in it, until we have a
>>>>> pretty good test harness for any new backend - e.g. Tribes
>>>>>
>>>>> It runs fine against AC and JG at the moment, but is not so happy
>>>>> with InVM :-(
>>>>>
>>>>> Would you mind taking a look, when you have time,
>>>>>
>>>>> Cheers :-)
>>>>>
>>>>>
>>>>> Jules
>>>>>
>>>>> P.S.
>>>>>
>>>>> Gianni and Filip,
>>>>>
>>>>> you may want to consider putting Tribes underneath this as a first
>>>>> test of the new backend...
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Gianny Damour wrote:

> Hi Jules,
>
> TestGroup is now passing on my local version. If you wait a little
> bit, I will commit my updates.
>
> Also, TestGroup does not pass with the AC backend on my box. Could you
> please confirm that it works on my machine? This is the reason why I
> have not yet checked in my local updates...
>
BTW - you have updated your tree recently ? I put in these changes over
the lasr couple of days.. They are definitely in and not just sitting in
my local filespace :-)

Jules

> Thanks,
> Gianny
>
> Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny,
>>
>>
>>
>> My bad !
>>
>> I've just taken a look at this - I had added an implementation of
>> 'waitForClusterToStart' - but on the shared rather than local Cluster
>> - so it didn't work, because all the peers are remote to the shared
>> one... - fixed that.
>> Ensured that setAddress(target) was called on outgoing messages as
>> the test uses this.
>> just looking at ensuring object identity for Addresses - so the same
>> Address is always '==' instead of just 'equals()' - WADI doesn't yet
>> need it, but I putting it into all backends so that we can soon use
>> this feature to avoid getting multiple views on a remote Peer in the
>> same local Peer.
>>
>> Jules
>>
>>>
>>> I've been rationalising the tests a bit more - coverage slowly
>>> rising :-)
>>>
>>> I have introduced a new test suite that can be run against our
>>> backends :
>>>
>>> ./wadi-dispatcher/src/test/java/org/codehaus/wadi/group/TestGroup.java
>>> ./wadi-jgroups/src/test/java/org/codehaus/wadi/jgroups/TestGroup.java
>>> ./wadi-activecluster/src/test/java/org/codehaus/wadi/activecluster/TestGroup.java
>>>
>>>
>>> In the dispatcher module, this test is written against the InVM impl.
>>> In the other backends it is subclassed and the InVM impl is replaced
>>> with the relevant backend.
>>> I hope to increase the number of tests in it, until we have a pretty
>>> good test harness for any new backend - e.g. Tribes
>>>
>>> It runs fine against AC and JG at the moment, but is not so happy
>>> with InVM :-(
>>>
>>> Would you mind taking a look, when you have time,
>>>
>>> Cheers :-)
>>>
>>>
>>> Jules
>>>
>>> P.S.
>>>
>>> Gianni and Filip,
>>>
>>> you may want to consider putting Tribes underneath this as a first
>>> test of the new backend...
>>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Gianny Damour-2]

Jules Gosnell wrote:
<snip>

> FYI - here is a breakdown of the borken (my side) InVM tests :
>
>        <exclude
> implementation="java.lang.String">**/TestInVMReplicationContextualiser.java</exclude><!--
> runs but throws exception -->

Do you have a stak trace? I do know that during the execution of this
test, a RDV expires and an exception is logged. This happens because the
ReplicationManager managing the primay session is no more reachable as
its node has failed. However, the ReplicationManager acquiring the
primary falls back to the replication storage and successfully
rehydrates a session.

>        <exclude
> implementation="java.lang.String">**/TestInVMEvacuation.java</exclude><!--
> runs but wong -->
>        <exclude
> implementation="java.lang.String">**/TestInVMRelocation.java</exclude><!--
> runs but wong -->
>
> 'runs but wrong' - means that whilst the test succeeds, I can tell
> from the output that not everything went to plan. In both cases
> something goes wrong with Partition negotiation and multiple copies of
> the same Partition arise and have to be resolved...

If you add a couple of additional asserts I should be able to give you a
hand for these tests.

Thanks,
Gianny

>
> I will start looking at this as soon as you get checked in.
>
> thanks,
>
> Jules

[Jules Gosnell-4]

Gianny,

In loooking at the reasns why the InVM stuff behaves differently in the
Relocation and Evacuation tests, I found an issue - The Map returned by
Cluster.getRemotePeers() should be Address:Peer, but was not for AC and
InVM.

I have added a test for this to the Group testsuite and fixed the AC
backend.

I was going to fix InVM as well, but it is having trouble with the
waitOnMembership() method as well (I had half of the Group testsuite
disabled by mistake :-( ). If was wondering if you might have time to
look at it tonight. I am going to see if I can get the final couple of
AC tests going now and the do some more thinking about the subsetting
stuff...

Jules


Gianny Damour wrote:

> Jules Gosnell wrote:
> <snip>
>
>> FYI - here is a breakdown of the borken (my side) InVM tests :
>>
>>        <exclude
>> implementation="java.lang.String">**/TestInVMReplicationContextualiser.java</exclude><!--
>> runs but throws exception -->
>
>
> Do you have a stak trace? I do know that during the execution of this
> test, a RDV expires and an exception is logged. This happens because
> the ReplicationManager managing the primay session is no more
> reachable as its node has failed. However, the ReplicationManager
> acquiring the primary falls back to the replication storage and
> successfully rehydrates a session.
>
>>        <exclude
>> implementation="java.lang.String">**/TestInVMEvacuation.java</exclude><!--
>> runs but wong -->
>>        <exclude
>> implementation="java.lang.String">**/TestInVMRelocation.java</exclude><!--
>> runs but wong -->
>>
>> 'runs but wrong' - means that whilst the test succeeds, I can tell
>> from the output that not everything went to plan. In both cases
>> something goes wrong with Partition negotiation and multiple copies
>> of the same Partition arise and have to be resolved...
>
>
> If you add a couple of additional asserts I should be able to give you
> a hand for these tests.
>
> Thanks,
> Gianny
>
>>
>> I will start looking at this as soon as you get checked in.
>>
>> thanks,
>>
>> Jules
>
>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Gianny,
>
> In loooking at the reasns why the InVM stuff behaves differently in
> the Relocation and Evacuation tests, I found an issue - The Map
> returned by Cluster.getRemotePeers() should be Address:Peer, but was
> not for AC and InVM.

figured that you weren't online - so fixed this... Test was not written
correctly (my bad) and VMLocalPeer was returning a Map of the wrong
types for getRemotePeer - oh for templates and static type checking :-)

Jules

>
> I have added a test for this to the Group testsuite and fixed the AC
> backend.
>
> I was going to fix InVM as well, but it is having trouble with the
> waitOnMembership() method as well (I had half of the Group testsuite
> disabled by mistake :-( ). If was wondering if you might have time to
> look at it tonight. I am going to see if I can get the final couple of
> AC tests going now and the do some more thinking about the subsetting
> stuff...
>
> Jules
>
>
> Gianny Damour wrote:
>
>> Jules Gosnell wrote:
>> <snip>
>>
>>> FYI - here is a breakdown of the borken (my side) InVM tests :
>>>
>>>        <exclude
>>> implementation="java.lang.String">**/TestInVMReplicationContextualiser.java</exclude><!--
>>> runs but throws exception -->
>>
>>
>>
>> Do you have a stak trace? I do know that during the execution of this
>> test, a RDV expires and an exception is logged. This happens because
>> the ReplicationManager managing the primay session is no more
>> reachable as its node has failed. However, the ReplicationManager
>> acquiring the primary falls back to the replication storage and
>> successfully rehydrates a session.
>>
>>>        <exclude
>>> implementation="java.lang.String">**/TestInVMEvacuation.java</exclude><!--
>>> runs but wong -->
>>>        <exclude
>>> implementation="java.lang.String">**/TestInVMRelocation.java</exclude><!--
>>> runs but wong -->
>>>
>>> 'runs but wrong' - means that whilst the test succeeds, I can tell
>>> from the output that not everything went to plan. In both cases
>>> something goes wrong with Partition negotiation and multiple copies
>>> of the same Partition arise and have to be resolved...
>>
>>
>>
>> If you add a couple of additional asserts I should be able to give
>> you a hand for these tests.
>>
>> Thanks,
>> Gianny
>>
>>>
>>> I will start looking at this as soon as you get checked in.
>>>
>>> thanks,
>>>
>>> Jules
>>
>>
>>
>>
>>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

[Jules Gosnell-4]

Gianny Damour wrote:

> Jules Gosnell wrote:
> <snip>
>
>> FYI - here is a breakdown of the borken (my side) InVM tests :
>>
>>        <exclude
>> implementation="java.lang.String">**/TestInVMReplicationContextualiser.java</exclude><!--
>> runs but throws exception -->
>
>
> Do you have a stak trace? I do know that during the execution of this
> test, a RDV expires and an exception is logged. This happens because
> the ReplicationManager managing the primay session is no more
> reachable as its node has failed. However, the ReplicationManager
> acquiring the primary falls back to the replication storage and
> successfully rehydrates a session.
>
>>        <exclude
>> implementation="java.lang.String">**/TestInVMEvacuation.java</exclude><!--
>> runs but wong -->
>>        <exclude
>> implementation="java.lang.String">**/TestInVMRelocation.java</exclude><!--
>> runs but wong -->
>>
>> 'runs but wrong' - means that whilst the test succeeds, I can tell
>> from the output that not everything went to plan. In both cases
>> something goes wrong with Partition negotiation and multiple copies
>> of the same Partition arise and have to be resolved...
>

I think that I have figured out why some tests run 'wrong'-ly...

It has to do with the way the first coordinator election occus in the
first node... - this is tricky, because different backends behave
differently... WADI has some complex (read horrible) code to deal with
this in DIndex, since I could not change the way that ACCluster behaved
(it doesn't perform an election at all if you are the first node up,
since it is never sure that there are no others ...).

Now that we own the AC backend, I shall add a test to the Group
testsuite, fix all backends to behave the same way and take all the
tricky code out of DIndex.

Jules

>
> If you add a couple of additional asserts I should be able to give you
> a hand for these tests.
>
> Thanks,
> Gianny
>
>>
>> I will start looking at this as soon as you get checked in.
>>
>> thanks,
>>
>> Jules
>
>
>
>

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/