Menu
▾
▴
#10 kiesett szerver visszaállása
Ha felmasolunk egy fajlt(4/3nal vagyunk) majd kilovunk
egy szervert, akkor nyugodtan le tudjuk meg masolni az
anyagot(torolni nem, mint lattuk) Visszainditva a
szervert, ha ezutan akarunk fajlt torolni vagy fajlt
felmasolni a LanStorera, akkor megfagy. A torles
hasonlit a masik hibara, de ott meg nem fut a kiesett
szerver, amikor torlunk, ugy hal meg. Itt viszont mar fut,
amikor torlest mondunk.
Ami komolyabb az a masolas. Ha ujrainditjuk a
szervert, anelkul, hogy barmilyen muvelet zajlott volna
es fajlt probalunk felmasolni, akkor lefut a folyamat, de
nem frissul GetFileListtel a LanStore panelja a muvelet
sikererol tajekoztatva. Ezutan barmilyen muveletet
probalunk meg, az meghal. Maga a kliens dob hibát,
lényeges része:
Unhandled Exception: System.IO.IOException: Unable
to write data to the transpor
t connection. --->
System.Net.Sockets.SocketException: An existing
connection wa
s forcibly closed by the remote host
Logged In: YES
user_id=1352749
A Server jraindtsval kapcsolatban a kvetkezőket
prbltam ki:
* connection pool kiiktatsa k+s oldalon
* N=2,K=1
* a szerverek nem dobnak Socket... kivtelt. Fellls utn
helloznak, s jl kapjk meg egyms zeneteit
* ha a kliensnl jl műkdik a file-transzfer mindkt
irnyban, akkor elvileg a szerverek kztt is kell mennie
fellls utn, mert ugyanazt a connection pool mechanizmust
hasznlja (gyk. a felllt szervernek gy kld cskokat,
mintha egy kliens lenne) szval gy kiiktatva nem hasznljuk
az "elvult" socketeket
Annyi tapasztalatom volt, hogy nekem mgsem ment a transzfer
kt szerver kztt, pedig a kiesett időben prbltam
msolni. Maga a msols sem ment az lő szerverre, pedig az
vezr volt. Ha neketek mgis menne, akkor lehet, hogy a
fenti javaslatom megoldja problmt (legalbbis rlnk neki:).
Annyi mg, hogy a kliensbe drtozztok bele a
NetClient.cs-be a port=19720-at, ami default. gy be brtok
tbbszr is jelentkezni vele.
Logged In: YES
user_id=1352749
A legfontosabbat nem rtam le: connection pool kiiktatsa.
A NetClient.cs / NetServer.cs -ben van egy
GetConnectedServer()/GetConnectedClient() fv. Abban a kv
kt sor (mindkettőben egyforma):
/*if (ns.m_sock.Connected)
return ns;*/
Ezt a fenti mdon kikommentezni, utna, ha a kliensporotot
bedrtozttok, akkor onnan tudjtok meg, hogy jl műkdik,
hogy tbbszr be tudtok jelentkezni ua a klienssel. :)
Logged In: YES
user_id=1353742
Megcsinltam amit mondtal, a kliens tenyleg kepes
csatlakozni tobbszor is, de mostmar a legelemibb felmasolas
sem megy, a kliens elszall egy hibaval(N4,K3).
Mit is csinaltam:
a NetClient.cs-ben a listenportot( ez se vilagos, hogy melyik
portot es hol? van kb haromfajta, neha parameterkent is)
irtam at, majd kommenteztem a megadott sorokat.
Ha tudsz, keszits mar egy mukodo valtozatot(magyarul ami
nalad van) es rakd fel a CVSbe, vagy a konyvtaradba a
WANCSAn, mint "tobbszorbekliens" knyvtr.
Ha pedig egyszerubb a megoldas, akkor sorra mond meg,
hol kell a portot bedrotozni(StartListen eljarasban, vagy hol?)
Logged In: YES
user_id=1352749
Sajnlom, hogy nem voltam egyrtelmű:
a NetClient osztlyban van egy member (listenport) azt
kellene fixen bektni.
pl. public int listenport=19720; (teht az első olyan
helyen, ahol listenport-ot olvasol:)
Ez azrt van, mert amikor a klienssel kijelentkezel, akkor
lepti a Network moduljt s jraindtskor valamirt
nemdeterminisztikusan nem mindig inicializlja s -1-el elszll
Ez nem tudom mirt van, de szeretnm kijavtani.
Az eredeti bughoz: ha tovbbra is gy műkdik connection
pool nlkl, mint vele, de legalbb az jraindult szervert
szreveszik a tbbiek, akkor j. A baj ott kezdődik, ha a
conn.pool nlkl az is elromlik, ami eddig ment (mrmint
funkciban). Mert akkor nagy gz van.
Vgső esetben mg azt tudom javasolni, hogy a kliensben
lltstok helyre a conn.pool-t, de a szerverekből
mindenkppen ki kell iktatni, ha szreveszitek, hogy egy lő
szerver fenntart a pool-jban egy halott szerverre mutat
socketet. Ekkor ugyanis jraindulskor tuti, hogy nem tud
neki kldeni cskokat tcp-n.
Most jttem r, hogy tegnap amikor lttk egymst
jraindts utn a szerverek, akkor az multicast volt, ami
mg nem jelent semmit. Szval n sem tudom biztosan, hogy
műkdtt-e nlam.
De azrt remlem tudtam valamit segteni.
Logged In: YES
user_id=1352749
A bug jelentlegi llapota: nem fut a
DataBaseUpdater-->VersionIncome(object o) fggvny aszinkron
mdban. Szinkronban pedig blokkolja a ServerAI-t.
Logged In: YES
user_id=1352749
Sikerlt az adatbzis helyrelltsa kiesett szerver esetn.
Az előző megjegyzsemre reaglva sikerlt az emltett
metdus aszinkron hvsa - erről majd bővebben szemlyesen :)
Tovbbra is N=2, K=1-el teszteltem. Teljesen jl lekezelte a
ServerAI a bejtt DB verziszmokat s rekonstrulta a sajt
Dbjt.
Itt tartok most.
Azt mg nem prbltam, hogy ha mindkettő szerver l, akkor
megy-e a felmsols/trls. Majd vasrnap este vagy htfőn
elkldm a vltoztatsokat s majd arra krnlek meg Imi,
hogy teszteld ki ms konfigra is.
Aminek mg utna kellene nzni: hogy Db helyrellts utn
cskok nem mennek szerverek kztt - ezt lehet, hogy nem is
tudja az AI? n legalbbis semmi erre utalt nem talltam a
kdban. Szval az a csk az elveszett... Ettől mg műkdhet
jl a rendszer, csak eszembe jutott :)