|
Dispatcher - some refactoring done
Hi,
I have checked in the refactoring of Dispatcher. Unfortunately, I did
not have enough time to reduce the number of message exchange contracts
defined by Dispatcher; having said that AbstractDispatcher is now more
maintainable.
From a testing perspective, I have checked all the ActiveCluster
integration tests (the ones starting with TestAC). I can not run the
JGroups tests on my box as my JVM core dump with the following details:
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
PC=0x807 7E4B
Function=[Unknown.]
Library=c:\Documents and Settings\gianny\My
Documents\applications\java\j2sdk1.4
.2_05\jre\bin\client\jvm.dll
Current Java thread:
at java.net.PlainDatagramSocketImpl.join(Native Method)
at
java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
va:158)
at java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
at
org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
1623)
at org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
at org.jgroups.protocols.TP.start(TP.java:374)
at org.jgroups.protocols.UDP.start(UDP.java:382)
at
org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
at org.jgroups.stack.DownHandler.run(Protocol.java:117)
Jules, could you please give a try to the JGroups tests?
Thanks,
Gianny
|
|
Re: Dispatcher - some refactoring done
Gianny Damour wrote:
> Hi,
>
> I have checked in the refactoring of Dispatcher. Unfortunately, I did
> not have enough time to reduce the number of message exchange
> contracts defined by Dispatcher; having said that AbstractDispatcher
> is now more maintainable.
>
> From a testing perspective, I have checked all the ActiveCluster
> integration tests (the ones starting with TestAC). I can not run the
> JGroups tests on my box as my JVM core dump with the following details:
>
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
> at PC=0x807 7E4B
> Function=[Unknown.]
> Library=c:\Documents and Settings\gianny\My
> Documents\applications\java\j2sdk1.4
> .2_05\jre\bin\client\jvm.dll
nasty !
I should have time to try them tonight - I'll get back to you then...
Thanks for doing this stuff, Gianny - it really needed it.
Jules
>
> Current Java thread:
> at java.net.PlainDatagramSocketImpl.join(Native Method)
> at
> java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
> va:158)
> at java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
> at
> org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
> 1623)
> at org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
> at org.jgroups.protocols.TP.start(TP.java:374)
> at org.jgroups.protocols.UDP.start(UDP.java:382)
> at
> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
> at org.jgroups.stack.DownHandler.run(Protocol.java:117)
>
> Jules, could you please give a try to the JGroups tests?
>
> Thanks,
> Gianny
>
--
"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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Gianny,
The JGroups tests may be failing because, for some reason, the latest
JGroups stack needs a -Djava.net.preferIPv4Stack=true property set, to
get them to work. This is passed to the surefire tests from the
top-level pom.xml... - give it a whirl and see if that fixes your problem...
I have run the bin/beetlejuice.sh script (the one run by our continuous
build system) and found one test failing - TestInVMReplication.java and
a few other Exceptions popping out here and there, but not actually
failing tests. I will take a closer look at all of these on tuesday -
after the Easter bank holiday.
Thanks for putting in the time to refactor this stuff - I have a number
of ideas about the direction that I would like to see the API between
WADI and our various backends go. I guess we should discuss these on the
list, just to make sure that we are all on the same page and to catch up
on where you have got to with this.... Would you mind posting a brief
summary of the changes made so far and any further changes that you feel
should be made ?
Thanks again,
Jules
Jules Gosnell wrote:
> Gianny Damour wrote:
>
>> Hi,
>>
>> I have checked in the refactoring of Dispatcher. Unfortunately, I did
>> not have enough time to reduce the number of message exchange
>> contracts defined by Dispatcher; having said that AbstractDispatcher
>> is now more maintainable.
>>
>> From a testing perspective, I have checked all the ActiveCluster
>> integration tests (the ones starting with TestAC). I can not run the
>> JGroups tests on my box as my JVM core dump with the following details:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
>> at PC=0x807 7E4B
>> Function=[Unknown.]
>> Library=c:\Documents and Settings\gianny\My
>> Documents\applications\java\j2sdk1.4
>> .2_05\jre\bin\client\jvm.dll
>
>
> nasty !
>
> I should have time to try them tonight - I'll get back to you then...
>
> Thanks for doing this stuff, Gianny - it really needed it.
>
>
> Jules
>
>>
>> Current Java thread:
>> at java.net.PlainDatagramSocketImpl.join(Native Method)
>> at
>> java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
>> va:158)
>> at java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
>> at
>> org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
>> 1623)
>> at
>> org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
>> at org.jgroups.protocols.TP.start(TP.java:374)
>> at org.jgroups.protocols.UDP.start(UDP.java:382)
>> at
>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>> at org.jgroups.stack.DownHandler.run(Protocol.java:117)
>>
>> Jules, could you please give a try to the JGroups tests?
>>
>> Thanks,
>> Gianny
>>
>
>
--
"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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Gianny,
I now have the JG Evacuation and Relocation tests working (I think!).
I've checked in minor changes to the JGroups backend.
I am turning my attention to the InVM tests, which although appearing to
work, actually behave very differently from the AC and JG backends... -
the tests should fail - but don't :-(.
I have fixed a couple of small issues, now I have found a bigger one...
I am wondering if it is something to do with the way that Partitions are
serialised/deserialised....
Does the InVM setup serialise/deserialise message content, or just pass
refs to POJOs around between pairs ?
If it does not go through the [de]serialisation step, can we add it via
e.g. an optional boolean constructor flag somewhere, as objects seem to
be 'coming across the wire' already initialised, when I am expecting
them to be uninitialised... If this turns out to be the issue, I will
look at making WADI work happily with serialisation disabled as well as
enabled, but, for the moment, I think that the easiest route forward is
to emulate the behaviour of the other backends as closely as possible,
until we get everything up and running again...
what do you think ?
Jules
Jules Gosnell wrote:
> Gianny,
>
> The JGroups tests may be failing because, for some reason, the latest
> JGroups stack needs a -Djava.net.preferIPv4Stack=true property set, to
> get them to work. This is passed to the surefire tests from the
> top-level pom.xml... - give it a whirl and see if that fixes your
> problem...
>
> I have run the bin/beetlejuice.sh script (the one run by our
> continuous build system) and found one test failing -
> TestInVMReplication.java and a few other Exceptions popping out here
> and there, but not actually failing tests. I will take a closer look
> at all of these on tuesday - after the Easter bank holiday.
>
> Thanks for putting in the time to refactor this stuff - I have a
> number of ideas about the direction that I would like to see the API
> between WADI and our various backends go. I guess we should discuss
> these on the list, just to make sure that we are all on the same page
> and to catch up on where you have got to with this.... Would you mind
> posting a brief summary of the changes made so far and any further
> changes that you feel should be made ?
>
> Thanks again,
>
> Jules
>
>
>
> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Hi,
>>>
>>> I have checked in the refactoring of Dispatcher. Unfortunately, I
>>> did not have enough time to reduce the number of message exchange
>>> contracts defined by Dispatcher; having said that AbstractDispatcher
>>> is now more maintainable.
>>>
>>> From a testing perspective, I have checked all the ActiveCluster
>>> integration tests (the ones starting with TestAC). I can not run the
>>> JGroups tests on my box as my JVM core dump with the following details:
>>>
>>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
>>> at PC=0x807 7E4B
>>> Function=[Unknown.]
>>> Library=c:\Documents and Settings\gianny\My
>>> Documents\applications\java\j2sdk1.4
>>> .2_05\jre\bin\client\jvm.dll
>>
>>
>>
>> nasty !
>>
>> I should have time to try them tonight - I'll get back to you then...
>>
>> Thanks for doing this stuff, Gianny - it really needed it.
>>
>>
>> Jules
>>
>>>
>>> Current Java thread:
>>> at java.net.PlainDatagramSocketImpl.join(Native Method)
>>> at
>>> java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
>>> va:158)
>>> at java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
>>> at
>>> org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
>>> 1623)
>>> at
>>> org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
>>> at org.jgroups.protocols.TP.start(TP.java:374)
>>> at org.jgroups.protocols.UDP.start(UDP.java:382)
>>> at
>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>>> at org.jgroups.stack.DownHandler.run(Protocol.java:117)
>>>
>>> Jules, could you please give a try to the JGroups tests?
>>>
>>> Thanks,
>>> Gianny
>>>
>>
>>
>
>
--
"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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Jules Gosnell wrote:
> Gianny,
>
> I now have the JG Evacuation and Relocation tests working (I think!).
> I've checked in minor changes to the JGroups backend.
>
> I am turning my attention to the InVM tests, which although appearing
> to work, actually behave very differently from the AC and JG
> backends... - the tests should fail - but don't :-(.
>
> I have fixed a couple of small issues, now I have found a bigger
> one... I am wondering if it is something to do with the way that
> Partitions are serialised/deserialised....
>
> Does the InVM setup serialise/deserialise message content, or just
> pass refs to POJOs around between pairs ?
I think that this is the isssue.
>
> If it does not go through the [de]serialisation step, can we add it
> via e.g. an optional boolean constructor flag somewhere, as objects
> seem to be 'coming across the wire' already initialised, when I am
> expecting them to be uninitialised... If this turns out to be the
> issue, I will look at making WADI work happily with serialisation
> disabled as well as enabled, but, for the moment, I think that the
> easiest route forward is to emulate the behaviour of the other
> backends as closely as possible, until we get everything up and
> running again...
>
> what do you think ?
Let me add this flag now. By default, all messages will be serialized.
Thanks,
Gianny
>
> Jules
>
>
> Jules Gosnell wrote:
>
>> Gianny,
>>
>> The JGroups tests may be failing because, for some reason, the latest
>> JGroups stack needs a -Djava.net.preferIPv4Stack=true property set,
>> to get them to work. This is passed to the surefire tests from the
>> top-level pom.xml... - give it a whirl and see if that fixes your
>> problem...
>>
>> I have run the bin/beetlejuice.sh script (the one run by our
>> continuous build system) and found one test failing -
>> TestInVMReplication.java and a few other Exceptions popping out here
>> and there, but not actually failing tests. I will take a closer look
>> at all of these on tuesday - after the Easter bank holiday.
>>
>> Thanks for putting in the time to refactor this stuff - I have a
>> number of ideas about the direction that I would like to see the API
>> between WADI and our various backends go. I guess we should discuss
>> these on the list, just to make sure that we are all on the same page
>> and to catch up on where you have got to with this.... Would you mind
>> posting a brief summary of the changes made so far and any further
>> changes that you feel should be made ?
>>
>> Thanks again,
>>
>> Jules
>>
>>
>>
>> Jules Gosnell wrote:
>>
>>> Gianny Damour wrote:
>>>
>>>> Hi,
>>>>
>>>> I have checked in the refactoring of Dispatcher. Unfortunately, I
>>>> did not have enough time to reduce the number of message exchange
>>>> contracts defined by Dispatcher; having said that
>>>> AbstractDispatcher is now more maintainable.
>>>>
>>>> From a testing perspective, I have checked all the ActiveCluster
>>>> integration tests (the ones starting with TestAC). I can not run
>>>> the JGroups tests on my box as my JVM core dump with the following
>>>> details:
>>>>
>>>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005)
>>>> occurred at PC=0x807 7E4B
>>>> Function=[Unknown.]
>>>> Library=c:\Documents and Settings\gianny\My
>>>> Documents\applications\java\j2sdk1.4
>>>> .2_05\jre\bin\client\jvm.dll
>>>
>>>
>>>
>>>
>>> nasty !
>>>
>>> I should have time to try them tonight - I'll get back to you then...
>>>
>>> Thanks for doing this stuff, Gianny - it really needed it.
>>>
>>>
>>> Jules
>>>
>>>>
>>>> Current Java thread:
>>>> at java.net.PlainDatagramSocketImpl.join(Native Method)
>>>> at
>>>> java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
>>>> va:158)
>>>> at java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
>>>> at
>>>> org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
>>>> 1623)
>>>> at
>>>> org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
>>>> at org.jgroups.protocols.TP.start(TP.java:374)
>>>> at org.jgroups.protocols.UDP.start(UDP.java:382)
>>>> at
>>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>>>> at org.jgroups.stack.DownHandler.run(Protocol.java:117)
>>>>
>>>> Jules, could you please give a try to the JGroups tests?
>>>>
>>>> Thanks,
>>>> Gianny
>>>>
>>>
>>>
>>
>>
>
>
|
|
Re: Dispatcher - some refactoring done
Gianny Damour wrote:
> Jules Gosnell wrote:
>
>> Gianny,
>>
>> I now have the JG Evacuation and Relocation tests working (I think!).
>> I've checked in minor changes to the JGroups backend.
>>
>> I am turning my attention to the InVM tests, which although appearing
>> to work, actually behave very differently from the AC and JG
>> backends... - the tests should fail - but don't :-(.
>>
>> I have fixed a couple of small issues, now I have found a bigger
>> one... I am wondering if it is something to do with the way that
>> Partitions are serialised/deserialised....
>>
>> Does the InVM setup serialise/deserialise message content, or just
>> pass refs to POJOs around between pairs ?
>
>
> I think that this is the isssue.
if we are lucky :-)
>
>>
>> If it does not go through the [de]serialisation step, can we add it
>> via e.g. an optional boolean constructor flag somewhere, as objects
>> seem to be 'coming across the wire' already initialised, when I am
>> expecting them to be uninitialised... If this turns out to be the
>> issue, I will look at making WADI work happily with serialisation
>> disabled as well as enabled, but, for the moment, I think that the
>> easiest route forward is to emulate the behaviour of the other
>> backends as closely as possible, until we get everything up and
>> running again...
>>
>> what do you think ?
>
>
> Let me add this flag now. By default, all messages will be serialized.
Thanks, Gianny - much appreciated.
Jules
>
> Thanks,
> Gianny
>
>>
>> Jules
>>
>>
>> Jules Gosnell wrote:
>>
>>> Gianny,
>>>
>>> The JGroups tests may be failing because, for some reason, the
>>> latest JGroups stack needs a -Djava.net.preferIPv4Stack=true
>>> property set, to get them to work. This is passed to the surefire
>>> tests from the top-level pom.xml... - give it a whirl and see if
>>> that fixes your problem...
>>>
>>> I have run the bin/beetlejuice.sh script (the one run by our
>>> continuous build system) and found one test failing -
>>> TestInVMReplication.java and a few other Exceptions popping out here
>>> and there, but not actually failing tests. I will take a closer look
>>> at all of these on tuesday - after the Easter bank holiday.
>>>
>>> Thanks for putting in the time to refactor this stuff - I have a
>>> number of ideas about the direction that I would like to see the
>>> API between WADI and our various backends go. I guess we should
>>> discuss these on the list, just to make sure that we are all on the
>>> same page and to catch up on where you have got to with this....
>>> Would you mind posting a brief summary of the changes made so far
>>> and any further changes that you feel should be made ?
>>>
>>> Thanks again,
>>>
>>> Jules
>>>
>>>
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny Damour wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have checked in the refactoring of Dispatcher. Unfortunately, I
>>>>> did not have enough time to reduce the number of message exchange
>>>>> contracts defined by Dispatcher; having said that
>>>>> AbstractDispatcher is now more maintainable.
>>>>>
>>>>> From a testing perspective, I have checked all the ActiveCluster
>>>>> integration tests (the ones starting with TestAC). I can not run
>>>>> the JGroups tests on my box as my JVM core dump with the following
>>>>> details:
>>>>>
>>>>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005)
>>>>> occurred at PC=0x807 7E4B
>>>>> Function=[Unknown.]
>>>>> Library=c:\Documents and Settings\gianny\My
>>>>> Documents\applications\java\j2sdk1.4
>>>>> .2_05\jre\bin\client\jvm.dll
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> nasty !
>>>>
>>>> I should have time to try them tonight - I'll get back to you then...
>>>>
>>>> Thanks for doing this stuff, Gianny - it really needed it.
>>>>
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> Current Java thread:
>>>>> at java.net.PlainDatagramSocketImpl.join(Native Method)
>>>>> at
>>>>> java.net.PlainDatagramSocketImpl.joinGroup(PlainDatagramSocketImpl.ja
>>>>> va:158)
>>>>> at
>>>>> java.net.MulticastSocket.joinGroup(MulticastSocket.java:355)
>>>>> at
>>>>> org.jgroups.protocols.TP$DiagnosticsHandler.bindToInterfaces(TP.java:
>>>>> 1623)
>>>>> at
>>>>> org.jgroups.protocols.TP$DiagnosticsHandler.start(TP.java:1588)
>>>>> at org.jgroups.protocols.TP.start(TP.java:374)
>>>>> at org.jgroups.protocols.UDP.start(UDP.java:382)
>>>>> at
>>>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>>>>> at org.jgroups.stack.DownHandler.run(Protocol.java:117)
>>>>>
>>>>> Jules, could you please give a try to the JGroups tests?
>>>>>
>>>>> Thanks,
>>>>> Gianny
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
"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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Jules,
Messages are now serialized. I think that it should work better now.
Sorry for the disruption resulting from the refactoring.
Thanks,
Gianny
Jules Gosnell wrote:
> Gianny Damour wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny,
>>>
>>> I now have the JG Evacuation and Relocation tests working (I
>>> think!). I've checked in minor changes to the JGroups backend.
>>>
>>> I am turning my attention to the InVM tests, which although
>>> appearing to work, actually behave very differently from the AC and
>>> JG backends... - the tests should fail - but don't :-(.
>>>
>>> I have fixed a couple of small issues, now I have found a bigger
>>> one... I am wondering if it is something to do with the way that
>>> Partitions are serialised/deserialised....
>>>
>>> Does the InVM setup serialise/deserialise message content, or just
>>> pass refs to POJOs around between pairs ?
>>
>>
>>
>> I think that this is the isssue.
>
>
> if we are lucky :-)
>
>>
>>>
>>> If it does not go through the [de]serialisation step, can we add it
>>> via e.g. an optional boolean constructor flag somewhere, as objects
>>> seem to be 'coming across the wire' already initialised, when I am
>>> expecting them to be uninitialised... If this turns out to be the
>>> issue, I will look at making WADI work happily with serialisation
>>> disabled as well as enabled, but, for the moment, I think that the
>>> easiest route forward is to emulate the behaviour of the other
>>> backends as closely as possible, until we get everything up and
>>> running again...
>>>
>>> what do you think ?
>>
>>
>>
>> Let me add this flag now. By default, all messages will be serialized.
>
>
> Thanks, Gianny - much appreciated.
>
> Jules
|
|
Re: Dispatcher - some refactoring done
Gianny Damour wrote:
> Jules,
>
> Messages are now serialized. I think that it should work better now.
> Sorry for the disruption resulting from the refactoring.
no problem...
I'll take another look at it all now and make sure that everything is
working smoothly...
Now that we own the API, we can start thinking about exactly what we
would like it to be - I have a number of ideas that I have had on the
backburner for a while. I may stick a couple of them in...
cheers,
Jules
>
> Thanks,
> Gianny
>
>
> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny,
>>>>
>>>> I now have the JG Evacuation and Relocation tests working (I
>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>
>>>> I am turning my attention to the InVM tests, which although
>>>> appearing to work, actually behave very differently from the AC and
>>>> JG backends... - the tests should fail - but don't :-(.
>>>>
>>>> I have fixed a couple of small issues, now I have found a bigger
>>>> one... I am wondering if it is something to do with the way that
>>>> Partitions are serialised/deserialised....
>>>>
>>>> Does the InVM setup serialise/deserialise message content, or just
>>>> pass refs to POJOs around between pairs ?
>>>
>>>
>>>
>>>
>>> I think that this is the isssue.
>>
>>
>>
>> if we are lucky :-)
>>
>>>
>>>>
>>>> If it does not go through the [de]serialisation step, can we add it
>>>> via e.g. an optional boolean constructor flag somewhere, as objects
>>>> seem to be 'coming across the wire' already initialised, when I am
>>>> expecting them to be uninitialised... If this turns out to be the
>>>> issue, I will look at making WADI work happily with serialisation
>>>> disabled as well as enabled, but, for the moment, I think that the
>>>> easiest route forward is to emulate the behaviour of the other
>>>> backends as closely as possible, until we get everything up and
>>>> running again...
>>>>
>>>> what do you think ?
>>>
>>>
>>>
>>>
>>> Let me add this flag now. By default, all messages will be serialized.
>>
>>
>>
>> Thanks, Gianny - much appreciated.
>>
>> 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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
found another problem with the invm stuff -
if you have a peer e.g. red running and you start another peer e.g.
green, red will get a nodeUpdate(green) notification before it gets a
nodeAdded(green) notification...
not sure how/why...
Gianny, do you want to take a look at it, or should I ?
Jules
Gianny Damour wrote:
> Jules,
>
> Messages are now serialized. I think that it should work better now.
> Sorry for the disruption resulting from the refactoring.
>
> Thanks,
> Gianny
>
>
> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny,
>>>>
>>>> I now have the JG Evacuation and Relocation tests working (I
>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>
>>>> I am turning my attention to the InVM tests, which although
>>>> appearing to work, actually behave very differently from the AC and
>>>> JG backends... - the tests should fail - but don't :-(.
>>>>
>>>> I have fixed a couple of small issues, now I have found a bigger
>>>> one... I am wondering if it is something to do with the way that
>>>> Partitions are serialised/deserialised....
>>>>
>>>> Does the InVM setup serialise/deserialise message content, or just
>>>> pass refs to POJOs around between pairs ?
>>>
>>>
>>>
>>>
>>> I think that this is the isssue.
>>
>>
>>
>> if we are lucky :-)
>>
>>>
>>>>
>>>> If it does not go through the [de]serialisation step, can we add it
>>>> via e.g. an optional boolean constructor flag somewhere, as objects
>>>> seem to be 'coming across the wire' already initialised, when I am
>>>> expecting them to be uninitialised... If this turns out to be the
>>>> issue, I will look at making WADI work happily with serialisation
>>>> disabled as well as enabled, but, for the moment, I think that the
>>>> easiest route forward is to emulate the behaviour of the other
>>>> backends as closely as possible, until we get everything up and
>>>> running again...
>>>>
>>>> what do you think ?
>>>
>>>
>>>
>>>
>>> Let me add this flag now. By default, all messages will be serialized.
>>
>>
>>
>> Thanks, Gianny - much appreciated.
>>
>> 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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Jules Gosnell wrote:
>
> found another problem with the invm stuff -
>
> if you have a peer e.g. red running and you start another peer e.g.
> green, red will get a nodeUpdate(green) notification before it gets a
> nodeAdded(green) notification...
>
> not sure how/why...
>
> Gianny, do you want to take a look at it, or should I ?
I have a simple, ugly fix for this - I am now looking at another issue...
In the case above - red is notified of green joining the cluster, but
green is not notified of red joining...
... investigating - maybe one my prior fixes has broken something ?
Jules
>
> Jules
>
>
> Gianny Damour wrote:
>
>> Jules,
>>
>> Messages are now serialized. I think that it should work better now.
>> Sorry for the disruption resulting from the refactoring.
>>
>> Thanks,
>> Gianny
>>
>>
>> Jules Gosnell wrote:
>>
>>> Gianny Damour wrote:
>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Gianny,
>>>>>
>>>>> I now have the JG Evacuation and Relocation tests working (I
>>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>>
>>>>> I am turning my attention to the InVM tests, which although
>>>>> appearing to work, actually behave very differently from the AC
>>>>> and JG backends... - the tests should fail - but don't :-(.
>>>>>
>>>>> I have fixed a couple of small issues, now I have found a bigger
>>>>> one... I am wondering if it is something to do with the way that
>>>>> Partitions are serialised/deserialised....
>>>>>
>>>>> Does the InVM setup serialise/deserialise message content, or just
>>>>> pass refs to POJOs around between pairs ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I think that this is the isssue.
>>>
>>>
>>>
>>>
>>> if we are lucky :-)
>>>
>>>>
>>>>>
>>>>> If it does not go through the [de]serialisation step, can we add
>>>>> it via e.g. an optional boolean constructor flag somewhere, as
>>>>> objects seem to be 'coming across the wire' already initialised,
>>>>> when I am expecting them to be uninitialised... If this turns out
>>>>> to be the issue, I will look at making WADI work happily with
>>>>> serialisation disabled as well as enabled, but, for the moment, I
>>>>> think that the easiest route forward is to emulate the behaviour
>>>>> of the other backends as closely as possible, until we get
>>>>> everything up and running again...
>>>>>
>>>>> what do you think ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Let me add this flag now. By default, all messages will be serialized.
>>>
>>>
>>>
>>>
>>> Thanks, Gianny - much appreciated.
>>>
>>> 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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
Jules Gosnell wrote:
> Jules Gosnell wrote:
>
>>
>> found another problem with the invm stuff -
>>
>> if you have a peer e.g. red running and you start another peer e.g.
>> green, red will get a nodeUpdate(green) notification before it gets a
>> nodeAdded(green) notification...
>>
>> not sure how/why...
>
looks like existing peers are notified about a new peer joining when its
VMLocalCluster.registerDispatcher() is called..., but when a peer joins
an existing Cluster, all the existing Peers have already called this
method and will not call it again - so they see the new Peer - but it
does not see them...
I think this is all pointing to the fact that we really need a very
simple and small backend testsuite that we can run against ac, jg, vm
and tribes to confirm the basic fn-ality that WADI requires. I will see
if I can knock something up over the next couple of days.
Jules
>>
>> Gianny, do you want to take a look at it, or should I ?
>
>
>
> I have a simple, ugly fix for this - I am now looking at another issue...
>
> In the case above - red is notified of green joining the cluster, but
> green is not notified of red joining...
>
> ... investigating - maybe one my prior fixes has broken something ?
>
> Jules
>
>>
>> Jules
>>
>>
>> Gianny Damour wrote:
>>
>>> Jules,
>>>
>>> Messages are now serialized. I think that it should work better now.
>>> Sorry for the disruption resulting from the refactoring.
>>>
>>> Thanks,
>>> Gianny
>>>
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny Damour wrote:
>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>> Gianny,
>>>>>>
>>>>>> I now have the JG Evacuation and Relocation tests working (I
>>>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>>>
>>>>>> I am turning my attention to the InVM tests, which although
>>>>>> appearing to work, actually behave very differently from the AC
>>>>>> and JG backends... - the tests should fail - but don't :-(.
>>>>>>
>>>>>> I have fixed a couple of small issues, now I have found a bigger
>>>>>> one... I am wondering if it is something to do with the way that
>>>>>> Partitions are serialised/deserialised....
>>>>>>
>>>>>> Does the InVM setup serialise/deserialise message content, or
>>>>>> just pass refs to POJOs around between pairs ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think that this is the isssue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> if we are lucky :-)
>>>>
>>>>>
>>>>>>
>>>>>> If it does not go through the [de]serialisation step, can we add
>>>>>> it via e.g. an optional boolean constructor flag somewhere, as
>>>>>> objects seem to be 'coming across the wire' already initialised,
>>>>>> when I am expecting them to be uninitialised... If this turns out
>>>>>> to be the issue, I will look at making WADI work happily with
>>>>>> serialisation disabled as well as enabled, but, for the moment, I
>>>>>> think that the easiest route forward is to emulate the behaviour
>>>>>> of the other backends as closely as possible, until we get
>>>>>> everything up and running again...
>>>>>>
>>>>>> what do you think ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Let me add this flag now. By default, all messages will be
>>>>> serialized.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks, Gianny - much appreciated.
>>>>
>>>> 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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
BTW - Gianny - I'm thinking that the dispatcher module should probably
be called 'group' now - what do you think ?
Jules
Gianny Damour wrote:
> Jules,
>
> Messages are now serialized. I think that it should work better now.
> Sorry for the disruption resulting from the refactoring.
>
> Thanks,
> Gianny
>
>
> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny,
>>>>
>>>> I now have the JG Evacuation and Relocation tests working (I
>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>
>>>> I am turning my attention to the InVM tests, which although
>>>> appearing to work, actually behave very differently from the AC and
>>>> JG backends... - the tests should fail - but don't :-(.
>>>>
>>>> I have fixed a couple of small issues, now I have found a bigger
>>>> one... I am wondering if it is something to do with the way that
>>>> Partitions are serialised/deserialised....
>>>>
>>>> Does the InVM setup serialise/deserialise message content, or just
>>>> pass refs to POJOs around between pairs ?
>>>
>>>
>>>
>>>
>>> I think that this is the isssue.
>>
>>
>>
>> if we are lucky :-)
>>
>>>
>>>>
>>>> If it does not go through the [de]serialisation step, can we add it
>>>> via e.g. an optional boolean constructor flag somewhere, as objects
>>>> seem to be 'coming across the wire' already initialised, when I am
>>>> expecting them to be uninitialised... If this turns out to be the
>>>> issue, I will look at making WADI work happily with serialisation
>>>> disabled as well as enabled, but, for the moment, I think that the
>>>> easiest route forward is to emulate the behaviour of the other
>>>> backends as closely as possible, until we get everything up and
>>>> running again...
>>>>
>>>> what do you think ?
>>>
>>>
>>>
>>>
>>> Let me add this flag now. By default, all messages will be serialized.
>>
>>
>>
>> Thanks, Gianny - much appreciated.
>>
>> 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.
**********************************/
|
|
Re: Dispatcher - some refactoring done
I do not have a strong opinion on this question.
Regarding the reported bugs, I have fixed all of them (I think that
TestVMCluster covers all the problems that you have raised).
Thanks,
Gianny
Jules Gosnell wrote:
> BTW - Gianny - I'm thinking that the dispatcher module should probably
> be called 'group' now - what do you think ?
>
> Jules
>
>
> Gianny Damour wrote:
>
>> Jules,
>>
>> Messages are now serialized. I think that it should work better now.
>> Sorry for the disruption resulting from the refactoring.
>>
>> Thanks,
>> Gianny
>>
>>
>> Jules Gosnell wrote:
>>
>>> Gianny Damour wrote:
>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Gianny,
>>>>>
>>>>> I now have the JG Evacuation and Relocation tests working (I
>>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>>
>>>>> I am turning my attention to the InVM tests, which although
>>>>> appearing to work, actually behave very differently from the AC
>>>>> and JG backends... - the tests should fail - but don't :-(.
>>>>>
>>>>> I have fixed a couple of small issues, now I have found a bigger
>>>>> one... I am wondering if it is something to do with the way that
>>>>> Partitions are serialised/deserialised....
>>>>>
>>>>> Does the InVM setup serialise/deserialise message content, or just
>>>>> pass refs to POJOs around between pairs ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I think that this is the isssue.
>>>
>>>
>>>
>>>
>>> if we are lucky :-)
>>>
>>>>
>>>>>
>>>>> If it does not go through the [de]serialisation step, can we add
>>>>> it via e.g. an optional boolean constructor flag somewhere, as
>>>>> objects seem to be 'coming across the wire' already initialised,
>>>>> when I am expecting them to be uninitialised... If this turns out
>>>>> to be the issue, I will look at making WADI work happily with
>>>>> serialisation disabled as well as enabled, but, for the moment, I
>>>>> think that the easiest route forward is to emulate the behaviour
>>>>> of the other backends as closely as possible, until we get
>>>>> everything up and running again...
>>>>>
>>>>> what do you think ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Let me add this flag now. By default, all messages will be serialized.
>>>
>>>
>>>
>>>
>>> Thanks, Gianny - much appreciated.
>>>
>>> Jules
>>
>>
>>
>>
>>
>
>
|
|
Re: Dispatcher - some refactoring done
Gianny Damour wrote:
> I do not have a strong opinion on this question.
OK - well, I'm in no hurry - lets give it a while and see how things pan
out...
>
> Regarding the reported bugs, I have fixed all of them (I think that
> TestVMCluster covers all the problems that you have raised).
cool - I will take a look at it.
Sorry that I haven't been pulling my weight the last few days. I've been
feeling lousy and had a pile of other things to deal with. I hope to
resume normal service very soon.
Jules
>
> Thanks,
> Gianny
>
> Jules Gosnell wrote:
>
>> BTW - Gianny - I'm thinking that the dispatcher module should
>> probably be called 'group' now - what do you think ?
>>
>> Jules
>>
>>
>> Gianny Damour wrote:
>>
>>> Jules,
>>>
>>> Messages are now serialized. I think that it should work better now.
>>> Sorry for the disruption resulting from the refactoring.
>>>
>>> Thanks,
>>> Gianny
>>>
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Gianny Damour wrote:
>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>> Gianny,
>>>>>>
>>>>>> I now have the JG Evacuation and Relocation tests working (I
>>>>>> think!). I've checked in minor changes to the JGroups backend.
>>>>>>
>>>>>> I am turning my attention to the InVM tests, which although
>>>>>> appearing to work, actually behave very differently from the AC
>>>>>> and JG backends... - the tests should fail - but don't :-(.
>>>>>>
>>>>>> I have fixed a couple of small issues, now I have found a bigger
>>>>>> one... I am wondering if it is something to do with the way that
>>>>>> Partitions are serialised/deserialised....
>>>>>>
>>>>>> Does the InVM setup serialise/deserialise message content, or
>>>>>> just pass refs to POJOs around between pairs ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think that this is the isssue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> if we are lucky :-)
>>>>
>>>>>
>>>>>>
>>>>>> If it does not go through the [de]serialisation step, can we add
>>>>>> it via e.g. an optional boolean constructor flag somewhere, as
>>>>>> objects seem to be 'coming across the wire' already initialised,
>>>>>> when I am expecting them to be uninitialised... If this turns out
>>>>>> to be the issue, I will look at making WADI work happily with
>>>>>> serialisation disabled as well as enabled, but, for the moment, I
>>>>>> think that the easiest route forward is to emulate the behaviour
>>>>>> of the other backends as closely as possible, until we get
>>>>>> everything up and running again...
>>>>>>
>>>>>> what do you think ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Let me add this flag now. By default, all messages will be
>>>>> serialized.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks, Gianny - much appreciated.
>>>>
>>>> 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.
**********************************/
|
