Well, that's right, I played with the total color demo.
It works allright, except when you start a new instance
while 2 others are transmitting.
I studied the program and saw that when a VIEW_CHANGE message
is send, total order is not respected. The VIEW_CHANGE message
is not received in same order on all parties.
This shows me that total order works ok on the message level.
But the thread that actually do the MethodCall is launched
via the Scheduler which handle two different kind of tasks :
standard task and priority task. Priority tasks are handled
by stopping others and starting the new priority task.
Whether method calls are handled with or without priority task,
launching threads for executing the method call might lead
to a reordering of method calls execution.=20
That's what I try to prove.
De : Vladimir Blagojevic [mailto:vladimir@...]
Envoy=E9 : jeu. 5 juin 2003 17:54
=C0 : DU SONG Romuald
Cc : JavaGroups
Objet : Re: [Javagroups-development] Question on total-token usage
Although I haven't tested TT with a test case you mention , why don;t you
try to use TT demo. It is in demos package. It "proves" that messages are
tottaly ordered by using colors. See if that works for you. For example
test scenario could be to turn on message sending from all participating
nodes, then all color changing views should be color synched and go
through same transformation. Transformations might not be happening at the
very same moment simultaneously (due to packet queuing delays, threading
delays on a computer node etc) but should go through same color transitions.
See if that works for you and then tell us what happened. If that works ok
then I don't see how you remote method invocation can fail? I would be
totally puzzled :)
On Thu, 5 Jun 2003, DU SONG Romuald wrote:
> But using this protocol to handle RpcDispatcher doesn't seems to work :
> remote method calls on replicas aren't total ordered.
Ce message et toutes les pi=E8ces jointes (ci-apr=E8s le "message") sont =
=E9tablis =E0 l'intention exclusive de ses destinataires et sont confidenti=
els. Si vous recevez ce message par erreur, merci de le d=E9truire et d'en =
avertir imm=E9diatement l'exp=E9diteur. Toute utilisation de ce message non=
conforme =E0 sa destination, modification, diffusion ou toute publication,=
totale ou partielle, est interdite, sauf autorisation expresse.FININFO (et=
ses filiales) d=E9cline(nt) toute responsabilit=E9 au titre de ce message,=
dans l'hypoth=E8se ou il aurait =E9t=E9 modifi=E9, alt=E9r=E9, falsifi=E9 =
ou encore =E9dit=E9 ou diffus=E9 sans autorisation.
This message and any attachments (the "message") is intended
solely for the addressees and is confidential. If you receive this=20
message in error, please delete it and immediately notify the=20
sender. Any use not in accord with its purpose, any dissemination=20
or disclosure, either whole or partial, is prohibited except formal=20
approval. Neither FININFO (nor any of its subsidiaries or affiliates)=20
shall be liable for the message if modified, altered, falsified, edited=20
or diffused without authorization.=20