Kenneth McWeeny wrote:
> Yes I tried it right away :)
>
> The SMACK updates for concurrency issues are similar to what I had
> tried but
> I like your solutions better. Cleaning up the windows upon removing a
> member
> was exactly what was needed. Now pulling the cable, reconnecting works and
> nodes are able to resume transmission both ways. You saved my bacon! :)
Glad to hear it works !
> Other changes I've added to SMACK:
>
> -AckMcastSenderWindow now keeps a retransmit counter for each seqno
> for each
> sender. If the max_xmits is exceeded for that message/sender combination,
> SMACK will suspect and remove that member. This behaviour is implied
> in the
> description/design for SMACK but was lacking the implementation. Gray's
> version of SMACK used a similar behaviour involving a max_timeout before
> retransmissions were cancelled to a sender
OK. Yes, somehow max_xmits functionality disappeared, or has never been
implemented in the first place ? :-)
> -The views are now generated in a consistent manner across all nodes.
> What I
> saw was that although each view had the same members, the order of the
> members, and the coordinator differed from node to node. Generally
> each node
> counted itself as the coordinator which caused problems with merging.
OK, good.
> Membership is now ordered lexically as members are added and removed
> and the
> first member is used as the coordinator/view owner at each node.
>
> -Added the ability to handle an Event.MERGE. This behaves like connect,
> sending a join announcement and eliciting join announcements from all
> other
> nodes, resulting in an updated view containing everyone.
>
> -Doing so allows SMACK to function perfectly with MERGE3. I did not
> have any
> luck using MERGE2 in stacks without GMS included, but MERGE3 was fine. I
> didn't try fast merge.
Unfortunately, MERGE3 is another unsupported protocol !
> -The SMACK join announcements and acks are changed to multicast messages
> since our project only uses multicast. This didn't require any changes
> other
> than setting dest = null
Hmm. OK.
> At this point I was able to get our main application up and running with
> most major functionality working again. Now I can work on getting simple
> state transfer back
This might turn out to be non trivial *to get it to transfer state
consistently with respect to other messages* ! You faced with either a
flush, where everybody stops sending messages, then transfer the state,
then everybody continues sending messages, or you do it at the
application level.
If your app can tolerate state that's not 100% consistent, e.g. by
assuming that subsequent operations will eventually bring the state into
sync, then that's not a problem.
> Thank you very much for fixing that behaviour for us on an unsupported
> protocol, you rock Bela!
Thanks, but do keep in mind that this is still an unsupported config. I
mean, to go from the current SMACK to a production ready version
requires more work.
If you could merge your version with Gray's changes, and commit the
result to JGroups, that'd be good. Maybe other folks are using SMACK as
well...
I don't want all-multicasts by default though, so maybe this part should
be configurable (false by default). But the max_xmits missing impl is
interesting...
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial.
http://p.sf.net/sfu/www-adobe-com_______________________________________________
javagroups-users mailing list
javagroups-users@...
https://lists.sourceforge.net/lists/listinfo/javagroups-users