Buildery dla AC - przem

[Andrzej Krzysztofowicz]

> On/Dnia Tue, Mar 25, 2003 at 01:24:31AM +0100, Andrzej Krzysztofowicz wrote/napisał(a)
> > Niezaleznie od tego jaki protokol zostanie tu przyjety powinien on zapewniac
> > mozliwie najwieksza niezawodnosc w przypadku krotko- i dlugotrwalego
> > polaczenia pomiadzy maszynami. Najlepszy bedzie protokol, ktory
> > bezposredniego polaczenia nie wymaga.
> > 
> [...]
> > W obecnych builderach brak retransmisji jest bardzo slabym punktem.
> Obecnie skrypt SPECS/builder ponownie dociąga źródła/spece/patche w
> przypadku gdy np. połączenie się z-timeoutuje/failnie itp. Buildery
> podczas scpowania również ponawiają próby tak, że nie jest tak źle.
> 
> Mniej więcej 1-2 dni może serwer cvs leżeć zanim się powyższe
> wznowienia skończą (kilkaset razy).

Nie dalej jak przedwczoraj builder ppc wysypal sie na timeoutach podczas
sciagania zrodel.
Inne chodzily.

Probowales przebudowac jednoczesnie cos wielkiego na wszyskich builderach?
Wszystkie sie sypaly na ciagnieciu zrodel: jeden OOM, pozostale timeout.
Wiem, ze tu problemem jest sam fakt umieszczania plikow w CVSie, niemniej
problem jest.

Czesto nie dziala kilka godzin/dzien/dwa serwer buildlogow i buildlogi gina.
Jak cos sie nie zbudowalo, to co najwyzej wystawca zlecenia wie dlaczego.

To samo z odsylaniem gotowych RPM-ow. Dodatkowo retransmisje blokuja
nastepne zlecenia. Zupelnie niepotrzebnie.

Dobrze by bylo, gdyby po puszczeniu zlecenia mozna bylo nie martwic sie o
problemy komunikacyjne.

Sadze, ze warto problem komunikacji rozwiazac calosciowo. I nie musi to byc
jeden protokol, moze byc kilka alternatywnych.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology