[Spread-users] spread connection error
MAGNIER Emmanuel [EIFFAGE ENERGIE]
Emmanuel.MAGNIER at eiffage.com
Mon May 15 03:05:08 EDT 2017
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 DebugFlags.
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 => GTC_T_PE1_PC3_Traces.txt till line 192
- spuser started on both computers, we sent messages => GTC_T_PE1_PC3_Traces.txt till line 213
- daemon started on GTC_T_ARC => GTC_T_PE1_PC3_Traces.txt till line 339
- daemon started on GTC_T_ACQ_Q3 => 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, spread is no more working.
On GTC_T_PE1_PC3, i tried to start spuser and got this error :
=========================================================
D:\Specifique\Spread>spuser.exe
Spread library version is 4.4.0
SP_error: (-6) Connection rejected, name not unique
Bye.
=========================================================
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'études
Tél. : +33 (0)9 53 43 79 29
-----Message d'origine-----
De : John Lane Schultz [mailto:jschultz at spreadconcepts.com]
Envoyé : mardi 2 mai 2017 16:43
À : MAGNIER Emmanuel [EIFFAGE ENERGIE] <Emmanuel.MAGNIER at eiffage.com>
Cc : spread-users at lists.spread.org; DELFOSSE Benjamin [EIFFAGE ENERGIE] <Benjamin.DELFOSSE at eiffage.com>
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 broadcast, or preferably, multicast transmission between all of the daemons in the segment.
> Which network masks/range ?
If your network gear supports it, then you should prefer to use multicast addresses for your segment addresses instead of broadcast addresses. That is more efficient, in terms of interrupts for uninvolved machines on the network, and you don't have to worry about getting your network masking / addressing 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 some Windows specific regressions may have been introduced at some point because we don't have a great environment in which to test large Windows deployments.
To better debug your problems, I'd need you to send some log file outputs from the daemons with the following debug flags enabled:
DebugFlags = { 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 might 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.MAGNIER at eiffage.com> 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 = 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 = 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, max computer per segment, max computers in the whole config .)
Thank you for your help
Best Regards
Emmanuel MAGNIER
Responsable d'études
Tél. : +33 (0)9 53 43 79 29
Cet e-mail et ses éventuelles pièces jointes peuvent contenir des informations confidentielles et sont exclusivement adressés au(x) destinataire(s) mentionné(s) ci-dessus. Toute diffusion, exploitation ou copie sans autorisation de cet e-mail et de ses pièces jointes est strictement interdite. Si vous recevez ce message par erreur, merci de le détruire et d' avertir immédiatement l'expéditeur. EIFFAGE décline toute responsabilité si ce message a été modifié ou falsifié.
This message and any attachments may contain confidential information and are established exclusively for his or its recipients. Any use of this message, 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 thereof. The EIFFAGE Group declines all responsibility concerning this message if it has been altered or tampered with. _______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.zip
Type: application/x-zip-compressed
Size: 18163 bytes
Desc: files.zip
URL: <http://lists.spread.org/pipermail/spread-users/attachments/20170515/da88a9f1/attachment-0001.bin>
More information about the Spread-users
mailing list