single members would cause messages not to be sent.
Also fixed an assertion in transition from multiple
processors to one processor.
(Logical change 1.62)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@211 fd59a12c-fef9-0310-b244-a6a79926bd2f
processing the token. This ensures that the mcast fd
doesn't buffer too many old messages and avoids an assert.
(Logical change 1.61)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@208 fd59a12c-fef9-0310-b244-a6a79926bd2f
of the members leaves, then a new configuration occurs
with 2 or more members, the "joined" list was not
being properly passed to the rest of the executive
services. This bug fixed.
(Logical change 1.53)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@167 fd59a12c-fef9-0310-b244-a6a79926bd2f
effect but allows the processor to participate in multicasting
and membership.
(Logical change 1.38)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@112 fd59a12c-fef9-0310-b244-a6a79926bd2f
that occurred during configuration changes. The result was bad
behavior, especially with larger rings. Also cleaned up the
token retransmit timer to be deleted if necessary.
(Logical change 1.37)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@110 fd59a12c-fef9-0310-b244-a6a79926bd2f
2004/07/12 14:37:13-07:00 mvista.com!sdake
When a processor left the membership, the next configuration would sometimes
cause a form token timeout. While not particularly harmful, it was wasteful
and not part of the original design of the group messaging protocol.
There was some extra junk code that was added to workaround some other bug
that has since been fixed.
This junk code removed and now the form token never times out (woohoo).
Also removed some extra code that calculates the next ORF processor twice.
We only really need to do it once.
(Logical change 1.33)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@100 fd59a12c-fef9-0310-b244-a6a79926bd2f
within a timeout period (100 msec). This helps avoid
a reconfiguration when only the token is lost, but no
real configuration changes have occured.
(Logical change 1.32)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@98 fd59a12c-fef9-0310-b244-a6a79926bd2f
didn't sent the appropriate configuration changes to the clm API
or to the rest of the services.
(Logical change 1.19)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@48 fd59a12c-fef9-0310-b244-a6a79926bd2f
it is possible to specify the bind network and
the networking will take place over that interface.
(Logical change 1.14)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@30 fd59a12c-fef9-0310-b244-a6a79926bd2f
UDP sockets, bind to specific interface defined in network.conf.
This is done by creating two fds. gmi_fd_token is used for all
token communication. gmi_fd_mcast is used for all mcast
communication. I'm not sure if gmi_fd_mcast binding rules is
correct. Once work begins on multipathing, this will have to
be figured out :)
2004/06/23 13:55:52-07:00 mvista.com!sdake
Use portable mreq instead of mreqn when joining the multicast
group.
(Logical change 1.13)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@26 fd59a12c-fef9-0310-b244-a6a79926bd2f
the recursion by queueing single node message delivery as a timer
with 0 timeout. This was happening before, but the logic was
wrong.
(Logical change 1.7)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@13 fd59a12c-fef9-0310-b244-a6a79926bd2f
because the initial send of the token is sent to the wrong address.
2004/06/16 15:42:49-07:00 mvista.com!sdake
Performance enhancements: Allow more messages to be multicast per
token possession to reach 8.8MB/sec checkpoint performance without
remcasts. Trim gather/commit timeouts to 100 msec to speed up the
membership gathering process.
(Logical change 1.5)
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@10 fd59a12c-fef9-0310-b244-a6a79926bd2f
