Re: spread connection error
John Lane Schultz <[email protected]> Tue, 23 May 2017 11:27:51 -0400
| Newsgroups | gmane.network.spread.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Emmanuel, I took a quick look at the logs and monitor output and I think there is som= ething wrong with the networking. In the monitor outputs, the segment retr= ansmissions by GTC_T_PE1_PC3 continually go up at a quite fast pace but no = messages are being delivered. A segment retransmission happens when multiple daemons in the same segment = miss a message. What I think is happening is that your broadcast in the se= cond segment isn=92t working. So, when any of them try to broadcast a mess= age, then the other two daemons in that segment don=92t hear it. = I assume you are sending through GTC_T_PE1_PC3 and/or GTC_T_PA1_MAI? = Those two daemons will receive each others messages because they send them = to each other via unicast, then GTC_T_PA1_MAI broadcasts for the rest of it= s segment, but they never hear it. They both mark the messages as missed, = which causes a segment retransmission. The problem is that the retransmiss= ion is also broadcast from GTC_T_PA1_MAI, which they never hear. And round= and round it goes with them never being able to recover the messages and p= rogress halts. It only truly breaks when you add the third daemon to the segment because w= ith only two daemons in the segment they will use unicast recovery to recov= er the messages, which does work. I don=92t know if this issue is because we changed the networking code for = broadcast that broke it on Windows, if Windows has changed how it handles b= roadcast, if your network addresses are wrong, or if there is a firewall so= mewhere blocking broadcast. I also don=92t know why GTC_T_PE1_PC3 would complain about =93name not uniq= ue=94 on the absolute FIRST client connection to Spread. Once it gets into= the above condition, then it may block input from clients (as it isn=92t m= aking progress), but then I=92d expect your client connections to be refuse= d, timeout or hang in some other manner. You can try to build the spsend.exe and sprecv.exe programs and see if you = can get broadcast or multicast to work in your segments. Another alternative is to put every daemon in its own segment. That will l= ikely work, but they will =93broadcast=94 messages to all the other daemons= by sending it unicast N times, once for each of the other daemons. If you= r application doesn=92t require high throughput, then that might be accepta= ble. Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On May 23, 2017, at 10:06 AM, MAGNIER Emmanuel [EIFFAGE ENERGIE] <Emmanuel.= [email protected]> wrote: Hi John, Were you able to look at provided logs ? The "name not unique" error appears when starting spuser for the first time= on the given computer, only daemon was running. Thank you. Best Regards Emmanuel MAGNIER Responsable d'=E9tudes T=E9l. : +33 (0)9 53 43 79 29 -----Message d'origine----- De : John Lane Schultz [mailto:[email protected]] = Envoy=E9 : lundi 15 mai 2017 18:40 =C0 : MAGNIER Emmanuel [EIFFAGE ENERGIE] <[email protected]> Objet : Re: [Spread-users] spread connection error Hi Emmanuel, I've received your reports and will look into them as soon as I can, but pr= obably not before Wednesday. The "name not unique" error means that Spread thinks a client is already co= nnected with the specified user name. You can specify a different user nam= e to spuser with the -u option (I believe, check the usage --help). We have had reports in the past of Spread not "releasing" a client connecti= on (and, therefore, its unique user name) even when the connection is broke= n. That might explain why subsequent attempts fail. If your first ever at= tempt to the daemon fails with that error, then that's a different bug. Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On May 15, 2017, at 3:05 AM, MAGNIER Emmanuel [EIFFAGE ENERGIE] <Emmanuel.M= [email protected]> wrote: Hi John, Thank you for explanations. Using multicast may not be allowed by our customer network gear. To the "first" spread.conf file previously sent, we added requested DebugFl= ags. Please find attached logs files from 3 computers : - *_traces.txt are log files made by spread.exe - *_sptmonitor_log.txt are log files with the output of sptmonitor Here's what we did : - every daemons shutdown, GTC_T_PE1_PC3 and GTC_T_PA1_MAI started =3D> GTC= _T_PE1_PC3_Traces.txt till line 192 - spuser started on both computers, we sent messages =3D> GTC_T_PE1_PC3_Tra= ces.txt till line 213 - daemon started on GTC_T_ARC =3D> GTC_T_PE1_PC3_Traces.txt till line 339 - daemon started on GTC_T_ACQ_Q3 =3D> GTC_T_PE1_PC3_Traces.txt till line 481 GTC_T_ACQ_Q3 is the 3rd started in Spread_Segment 172.23.164.255:4803, spre= ad is no more working. On GTC_T_PE1_PC3, i tried to start spuser and got this error : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D D:\Specifique\Spread>spuser.exe Spread library version is 4.4.0 SP_error: (-6) Connection rejected, name not unique Bye. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D I don't understand this error "name not unique". = In the past, we also got "connection refused" error. Please help us to find out what happen and how to make it works. Thank you Best Regards Emmanuel MAGNIER Responsable d'=E9tudes T=E9l. : +33 (0)9 53 43 79 29 -----Message d'origine----- De : John Lane Schultz [mailto:[email protected]] Envoy=E9 : mardi 2 mai 2017 16:43 =C0 : MAGNIER Emmanuel [EIFFAGE ENERGIE] <[email protected]> Cc = : [email protected]; DELFOSSE Benjamin [EIFFAGE ENERGIE] <Benja= [email protected]> Objet : Re: [Spread-users] spread connection error Hi Emmanuel, = > How many segments should we use ? Your segments should correspond to your LANs that support single-hop broadc= ast, or preferably, multicast transmission between all of the daemons in th= e segment. > Which network masks/range ? If your network gear supports it, then you should prefer to use multicast a= ddresses for your segment addresses instead of broadcast addresses. That i= s more efficient, in terms of interrupts for uninvolved machines on the net= work, and you don't have to worry about getting your network masking / addr= essing exactly correct. > Are there any limits in spread use hit by our config ? (max segments, = > max computer per segment, max computers in the whole config .) In 4.4, there should be no new limitations on the number of daemons you can= have in a segment or in a configuration. It is possible, however, that so= me Windows specific regressions may have been introduced at some point beca= use we don't have a great environment in which to test large Windows deploy= ments. To better debug your problems, I'd need you to send some log file outputs f= rom the daemons with the following debug flags enabled: DebugFlags =3D { PRINT EXIT CONFIGURATION MEMBERSHIP } If you could also run an sp_monitor at the same time and have it query the = status of all the involved daemons and give me some of that output, that mi= ght help too. Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On Apr 28, 2017, at 8:34 AM, MAGNIER Emmanuel [EIFFAGE ENERGIE] <Emmanuel.M= [email protected]> wrote: Dear spread users, We're upgrading an old setup made with : . Spread 3 . Windows XP computers . Windows 2003 computers To this new setup : . Spread 4.4 . Windows 10 computers . Windows 2016 computers First spread.conf : Spread_Segment 172.21.164.255:4803 { GTC_T_ACQ_Q1 172.21.164.10 GTC_T_PE1_Q1 172.21.164.11 } Spread_Segment 172.22.164.255:4803 { GTC_T_ACQ_Q2 172.22.164.10 GTC_T_PE1_Q2 172.22.164.11 GTC_T_PE1_PC3 172.22.164.15 GTC_T_PE2_PC3 172.22.164.16 GTC_T_BDD 172.22.164.19 GTC_T_ACQ_GTE 172.22.164.22 GTC_T_PE3_CLI 172.22.164.23 GTC_T_PE1_GTE 172.22.164.25 } Spread_Segment 172.23.164.255:4803 { GTC_T_ACQ_Q3 172.23.164.10 GTC_T_PE1_Q3 172.23.164.11 GTC_T_PA1_MAI 172.23.164.15 GTC_T_ARC 172.23.164.24 } Spread_Segment 172.24.164.255:4803 { GTC_T_ACQ_Q4 172.24.164.10 GTC_T_PE1_Q4 172.24.164.11 GTC_T_PA1_ADM 172.24.164.15 # GTC_T_PA1_BDT 172.24.164.16 GTC_T_PE1_CLI 172.24.164.18 GTC_T_PE2_CLI 172.24.164.19 GTC_T_AS1_Q4 172.24.164.25 GTC_T_AS2_Q4 172.24.164.27 GTC_T_PE4_CLI 172.24.164.28 GTC_T_PE1_SI1 172.24.164.50 VERDI 172.24.164.240 } Spread_Segment 172.27.112.255:4803 { GTC_B_ACQ 172.27.112.10 GTC_B_PE1_PCS 172.27.112.13 GTC_B_PA1_ADM 172.27.112.16 } Spread_Segment 172.26.146.255:4803 { GTC_R_ACQ 172.26.146.10 GTC_R_PE1_CLI 172.26.146.12 GTC_R_PA1_ADM 172.26.146.14 GTC_R_PE1_GTE 172.26.146.18 } Spread_Segment 172.28.116.255:4803 { GTC_A_PE1_PCS 172.28.116.12 GTC_A_ACQ 172.28.116.14 } #Spread_Segment 172.20.16.255:4803 { # VERDI 172.20.16.87 #} DangerousMonitor =3D true This doesn't work : . When starting spread.exe on more than 2 computers in the same segments OR . When starting spread.exe on more than 8 computers We're getting "spread connection refused" error. We tried this second spread.conf : Spread_Segment 172.21.164.255:4803 { GTC_T_ACQ_Q1 172.21.164.10 GTC_T_PE1_Q1 172.21.164.11 } Spread_Segment 172.22.164.255:4803 { GTC_T_ACQ_Q2 172.22.164.10 GTC_T_PE1_Q2 172.22.164.11 } Spread_Segment 172.22.164.255:4803 { GTC_T_PE1_PC3 172.22.164.15 GTC_T_PE2_PC3 172.22.164.16 } Spread_Segment 172.22.164.255:4803 { GTC_T_BDD 172.22.164.19 GTC_T_ACQ_GTE 172.22.164.22 } Spread_Segment 172.22.164.255:4803 { GTC_T_PE3_CLI 172.22.164.23 GTC_T_PE1_GTE 172.22.164.25 } Spread_Segment 172.23.164.255:4803 { GTC_T_ACQ_Q3 172.23.164.10 GTC_T_PE1_Q3 172.23.164.11 } Spread_Segment 172.23.164.255:4803 { GTC_T_PA1_MAI 172.23.164.15 GTC_T_ARC 172.23.164.24 } Spread_Segment 172.24.164.255:4803 { GTC_T_ACQ_Q4 172.24.164.10 GTC_T_PE1_Q4 172.24.164.11 } Spread_Segment 172.24.164.255:4803 { GTC_T_PA1_ADM 172.24.164.15 # GTC_T_PA1_BDT 172.24.164.16 } Spread_Segment 172.24.164.255:4803 { GTC_T_PE1_CLI 172.24.164.18 GTC_T_PE2_CLI 172.24.164.19 } Spread_Segment 172.24.164.255:4803 { GTC_T_AS1_Q4 172.24.164.25 GTC_T_AS2_Q4 172.24.164.27 } Spread_Segment 172.24.164.255:4803 { GTC_T_PE4_CLI 172.24.164.28 GTC_T_PE1_SI1 172.24.164.50 } Spread_Segment 172.24.164.255:4803 { VERDI 172.24.164.240 } Spread_Segment 172.27.112.255:4803 { GTC_B_ACQ 172.27.112.10 GTC_B_PE1_PCS 172.27.112.13 } Spread_Segment 172.27.112.255:4803 { GTC_B_PA1_ADM 172.27.112.16 } Spread_Segment 172.26.146.255:4803 { GTC_R_ACQ 172.26.146.10 GTC_R_PE1_CLI 172.26.146.12 } Spread_Segment 172.26.146.255:4803 { GTC_R_PA1_ADM 172.26.146.14 GTC_R_PE1_GTE 172.26.146.18 } Spread_Segment 172.28.116.255:4803 { GTC_A_PE1_PCS 172.28.116.12 GTC_A_ACQ 172.28.116.14 } #Spread_Segment 172.20.16.255:4803 { # VERDI 172.20.16.87 #} DangerousMonitor =3D true It seems better with few computers (others aren't installed yet), but it's = still strange for us. Please advise us about : . How many segments should we use ? . Which network masks/range ? . Are there any limits in spread use hit by our config ? (max segments, ma= x computer per segment, max computers in the whole config .) Thank you for your help Best Regards Emmanuel MAGNIER Responsable d'=E9tudes T=E9l. : +33 (0)9 53 43 79 29 Cet e-mail et ses =E9ventuelles pi=E8ces jointes peuvent contenir des infor= mations confidentielles et sont exclusivement adress=E9s au(x) destinataire= (s) mentionn=E9(s) ci-dessus. Toute diffusion, exploitation ou copie sans a= utorisation de cet e-mail et de ses pi=E8ces jointes est strictement interd= ite. Si vous recevez ce message par erreur, merci de le d=E9truire et d' av= ertir imm=E9diatement l'exp=E9diteur. EIFFAGE d=E9cline toute responsabilit= =E9 si ce message a =E9t=E9 modifi=E9 ou falsifi=E9. = This message and any attachments may contain confidential information and a= re established exclusively for his or its recipients. Any use of this messa= ge, for which it was not intended, any distribution or any total or partial= publication is prohibited unless previously approved. If you receive this = message in error, please destroy it and immediately notify the sender there= of. The EIFFAGE Group declines all responsibility concerning this message i= f it has been altered or tampered with. ___________________________________= ____________ Spread-users mailing list [email protected] https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flists.s= pread.org%2Fmailman%2Flistinfo%2Fspread-users&data=3D02%7C01%7CEmmanuel.MAG= NIER%40eiffage.com%7Cc6c4b6defb8b47594a7b08d49bb10150%7C2ed0a394379b4092aae= e9dce8bdb4f2d%7C1%7C0%7C636304631944148984&sdata=3Dr4zx3%2BuTNIXyqN%2F13979= WGyB7lOG%2FhjH%2FI0%2F%2BM52ZoU%3D&reserved=3D0 <files.zip>_______________________________________________ Spread-users mailing list [email protected] https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flists.s= pread.org%2Fmailman%2Flistinfo%2Fspread-users&data=3D02%7C01%7CEmmanuel.MAG= NIER%40eiffage.com%7Cc6c4b6defb8b47594a7b08d49bb10150%7C2ed0a394379b4092aae= e9dce8bdb4f2d%7C1%7C0%7C636304631944148984&sdata=3Dr4zx3%2BuTNIXyqN%2F13979= WGyB7lOG%2FhjH%2FI0%2F%2BM52ZoU%3D&reserved=3D0