Hi Steven,

Would you comment on my idea below? This fixes ifdown/ifup issue at least
manually.

Rather than calling totemnet_iface_check() from totemrrp_ring_reenable(), I
added renew_mcast_membership() in totemudp.c and called it from
totemrrp_ring_reenable().

Thanks
hj

On Tue, Feb 9, 2010 at 7:05 PM, hj lee <[email protected]> wrote:

> Hi,
>
> There were many discussions about this ifdown/ifup and we know that
> corosync rrp does not work well with ifdown/ifup. Most cases
> corosync-cfgtool -r does not resolve it. I found the main cause of this
> issue, that is multicast membership.
>
> My rrp_mode is passive. When I do ifdown/ifup, I found that FAULTY was
> always set only from passive_mcast_recv(). By looking the actual traffic,
> the token is received OK, but no multicast message on the interface I did
> ifdown/ifup. The corosync-cfgtool -r does not help at all. What I found was
> the socket itself survives, but the multicast membership is lost across
> ifdown/ifup.
>
> I resolved this issue by adding totemnet_iface_check(net_handlers[i]) if
> the interface is FAULTY in totemrrp_ring_reenable(). This call will close
> current sockets, create new sockets and rejoin to the multicast. Actually it
> does have to close old sockets and create new one, but that is the only
> function exposed to totemrrp, so I just use it to recover multicast
> membership. It will be good to have like multicast_join()/multicast_leave()
> functions, then just need to call
>
> multicast_leave();
> multicast_join();
>
> This will resolve ifdown/ifup issue manual way. I still think this issue
> can be recovered automatically by using netif_check timer.
>
> Thanks
> hj
>



-- 
Peakpoint Service

Cluster Setup, Troubleshooting & Development
[email protected]
(303) 997-2823
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais

Reply via email to