Bug in multicast implementation from class?

[Oren]

Hi,

I am experiencing some errors with the multicast implementation from
ptcrepo (i.e. the one done by the student group) that I did not
experience with the multicast.rb from the Bud sandbox.
If we try to use the ptcrepo multicast with a BestEffortDelivery
delivery protocol, we get a key constraint error:

==============================
test_twopc(TestTwoPC):
Bud::KeyConstraintError: exception during Bud evaluation.
Exception: #<Bud::KeyConstraintError: key conflict inserting [1, 3]
into "unacked_count": existing tuple [1, 0], key_cols = [1]>.
Rule: unacked_count <= ((mcast_send * num_members).pairs { |s, c|
[s.ident, c.num] })
/usr/lib/ruby/gems/1.8/gems/bud-0.0.7/lib/bud.rb:843:in
`stratum_fixpoint'
/usr/lib/ruby/gems/1.8/gems/bud-0.0.7/lib/bud/collections.rb:
110:in `each_with_index'
==============================

and if we try to use it with ReliableDelivery we get this strange
error

==============================
Loaded suite test/tc_2pc
Started
Bud::Error: bad inbound message of class Array: ["bed__pipe_chan",
["127.0.0.1:12346", "127.0.0.1:12345", 1, "QUERY"]]
E
Finished in 1.758432 seconds.

1) Error:
test_twopc(TestTwoPC):
Bud::ShutdownWithCallbacksError: Bud instance shutdown before
sync_callback completed
/usr/lib/ruby/gems/1.8/gems/bud-0.0.7/lib/bud.rb:546:in
`sync_callback'
test/tc_2pc_jon.rb:39:in `test_twopc'
==============================

What does "bad inbound message" mean?

Anyway, I'm not really sure if this is a bug with the multicast
implementation or not, but it would seem to be the case, since at
least when including BestEffortDelivery with the original multicast,
things worked fine, but here they generate a key conflict error.

Thanks!

Oren

[Eric Shih]

As a side note, I noticed that the multicast.rb uses
BestEffortDelivery and ReliableDelivery, but that no such require of a
file with these modules was included in the version in the
new_sandbox. Similarly, multicast.rb requires voting/voting, which is
from the existing bud-sandbox, instead of the new vote.rb, and it was
my impression that the existing voting.rb was not necessarily
"production ready", whereas the vote.rb was supposed to be. My concern
follows Hui Peng Hu's previous post of whether or not the new sandbox
is fully up to date/can be reliably counted upon for our current
projects.

[Peter Alvaro]

it's possible that the multicast code I committed into new_sandbox isn't the latest.

team multicast, what does it look like?

[Oren]

In fact there seem to be some really bizarre text in multicast.rb that
wouldn't let it be executed by the Ruby/bud interpreter:

https://github.com/programthecloud/ptcrepo/blob/gh-pages/new_sandbox/multicast/multicast.rb

Check out the very first line and also line 75.

[Oren]

Ahh -- it seems like multicast and the test code for multicast got
combined into one file there. But.. still, the multicast portion
(lines 2-75 or so) is what I used and what resulted in the errors I
ran into and mentioned in the original post.

On Dec 9, 1:27 pm, Oren <oblasb...@gmail.com> wrote:
> In fact there seem to be some really bizarre text in multicast.rb that
> wouldn't let it be executed by the Ruby/bud interpreter:
>

> https://github.com/programthecloud/ptcrepo/blob/gh-pages/new_sandbox/...

[Rising Sun]

For the first error:

unacked_count <= ((mcast_send * num_members).pairs { |s, c| [s.ident,
c.num] })

initializes the expected number of acks based on the number of
members. Somehow 3 new members are being added in after time starts
ticking.

I'm not sure what the second error means. If you're importing try
including instead and vice versa.

Don't worry about requiring voting, we don't actually use it. We
forgot to delete it from the module.

[Peter Alvaro]

ron: shall I remove the require in the ptcrepo source?  or did you want to send me an updated version?

[Alex Degtiar]

Peter: You can remove the require statement from the source.

Oren: For the error you're getting, it seems that the error message
indicates that a message was inserted into mcast_send with an id that
was already previously inserted. Messages put into mcast_send need to
have unique id so that the module can keep track of when all members
have confirmed sending that message. This requirement seems to have
been violated. This requirement was also not there for the previous
version of multicast, so this may explain the difference you are
seeing.

Do you think this may be the case based on your usage of the module?