Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 606196 Details for
Bug 850757
When flushing, discard only memb_join messages
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
Proposed patch
0001-When-flushing-discard-only-memb_join-messages.patch (text/plain), 3.01 KB, created by
Jan Friesse
on 2012-08-22 11:05:20 UTC
(
hide
)
Description:
Proposed patch
Filename:
MIME Type:
Creator:
Jan Friesse
Created:
2012-08-22 11:05:20 UTC
Size:
3.01 KB
patch
obsolete
>From 17e15322b7500247c539166441fb2e78cc95d02b Mon Sep 17 00:00:00 2001 >From: Jerome FLESCH <jerome.flesch@netasq.com> >Date: Mon, 11 Jun 2012 10:55:52 +0200 >Subject: [PATCH] When flushing, discard only memb_join messages > >Patch solves problem when 1 ring out of 2 went up/down quite often. > >The simplest setup to reproduce bug is following: >- 2 VMs, connected by 2 network interfaces >- OS: Linux >- On one of the VMs, a test program sending some CPG messages (see the > script "test_corosync.sh" joined to this mail for example) > >Here are the Corosync logs we get when we do this setup: > >Jun 06 16:23:40 corosync [TOTEM ] A processor joined or left the >membership and a new membership was formed. >Jun 06 16:23:40 corosync [CPG ] chosen downlist: sender r(0) >ip(192.168.56.104) r(1) ip(192.168.57.104) ; members(old:1 left:0) >Jun 06 16:23:40 corosync [MAIN ] Completed service synchronization, >ready to provide service. >Jun 06 16:24:37 corosync [TOTEM ] Marking ringid 1 interface >192.168.57.105 FAULTY >Jun 06 16:24:38 corosync [TOTEM ] Automatically recovered ring 1 >Jun 06 16:25:33 corosync [TOTEM ] Marking ringid 1 interface >192.168.57.105 FAULTY >Jun 06 16:25:34 corosync [TOTEM ] Automatically recovered ring 1 >Jun 06 16:26:35 corosync [TOTEM ] Marking ringid 1 interface >192.168.57.105 FAULTY >Jun 06 16:26:36 corosync [TOTEM ] Automatically recovered ring 1 >(...) > >The second ring goes down about every 2 minutes and automatically back >up right after. > >We spent some times looking for the commit that introduced this bug, and >it appears it's due the following one: >Corosync 1.3.3 -> 1.3.4: e27a58d93d0d3795beb550f87b660c9c04f11386 >Corosync 1.4.1 -> 1.4.2: be608c050247e5f9c8266b8a0f9803cc0a3dc881 >Commit message: Ignore memb_join messages during flush operations > >I had a look at this commit, and it seems to me it's dropping too many >packets: >Because of this commit, while totemrrp_recv_flush() is called, Corosync >drops memb_join packets, but also ORF tokens. In the end, it seems that >sometimes, we drop so many of them that Corosync marks the ring as >faulty. > >To fix that, only memb_join messages are dropped now. > >Signed-off-by: Jerome FLESCH <jerome.flesch@netasq.com> >Reviewed-by: Steven Dake <sdake@redhat.com> >Reviewed-by: Jan Friesse <jfriesse@redhat.com> >(backported from commit 99faa3b864e3ff12f78cdfd8be56e4e6393e3c2e) >--- > exec/totemudp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/exec/totemudp.c b/exec/totemudp.c >index a912b6a..52628e7 100644 >--- a/exec/totemudp.c >+++ b/exec/totemudp.c >@@ -90,7 +90,7 @@ > #define BIND_STATE_REGULAR 1 > #define BIND_STATE_LOOPBACK 2 > >-#define MESSAGE_TYPE_MCAST 1 >+#define MESSAGE_TYPE_MEMB_JOIN 3 > > #define HMAC_HASH_SIZE 20 > struct security_header { >@@ -1252,7 +1252,7 @@ static int net_deliver_fn ( > * messages should be dropped) > */ > message_type = (char *)msg_offset; >- if (instance->flushing == 1 && *message_type != MESSAGE_TYPE_MCAST) { >+ if (instance->flushing == 1 && *message_type == MESSAGE_TYPE_MEMB_JOIN) { > iovec->iov_len = FRAME_SIZE_MAX; > return (0); > } >-- >1.7.10.1 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 850757
: 606196