Sziasztok, adott az alabbi konfig (relevans resz): Service( \ "intra_http", \ MyHTTP, \ router = DirectedRouter( [SockAddrInet("10.15.0.63", 80), \ SockAddrInet("10.15.0.73", 80)] ), \ chainer = FailoverChainer( round_robin = TRUE )) (Debian Etch, Zorp GPL 3.0.8) Azt tapasztalom, hogy miutan az egyik back-end leall, akkor a Zorp tovabbra is probal mindkettohoz konnektalni. Ez a logokbol derul ki, illetve lassabb lesz az alkalmazas mukodese - de mukodik minden. Milyen lehetosegeim vannak, hogy ezt a failover funkciot teljes egeszeben kihasznaljam, es a Zorp eszrevegye, hogy az egyik kiszolgalo eltunt? Neztem a FailoverChainer() osztalyt, ott van a konstruktorban timeout, de az default 0, en pedig nem allitom explicit az erteket (lasd konfig). Koszonom: a.
Szia!
Neztem a FailoverChainer() osztalyt, ott van a konstruktorban timeout, de az default 0, en pedig nem allitom explicit az erteket (lasd konfig).
Jól látod, tényleg FailOverChainer osztaly timeout-ját kell állítanod, csak a neve kicsit megtévesztő. Ez a timeout ugyanis nem azt jelenti, hogy ha a cél ennyi ideig nem válaszol akkor tekinti a célt elérhetetlennek (arra ott a lentebbi protokoll, pl TCP), hanem ez azt jeleneti, hogy ha egy cél már nem elérhető, ennyi ideig nem próbálkozik újra. Szóval ha azt akarod, hogy a ha a cél nem elérhető egy darabig ne próbálkozzon, emeled ezt a timeout-ot. Viszont ha a cél visszajön (max) ennyi nem is veszi majd észre. Üdv, Höltzl Péter -- BalaBit IT Bizt. Kft | Tel: +36 1 371-0540 | GnuPG Fingerprint: holtzl.peter@balabit.hu | Mobil: +36 20 366-9667 | 2831 E951 B9EE 63BB F0F4 http://www.balabit.hu/ | Fax: +36 1 208-0875 | 2F4A 1EA4 4B12 7638 29C0
hello,
Neztem a FailoverChainer() osztalyt, ott van a konstruktorban timeout, de az default 0, en pedig nem allitom explicit az erteket (lasd konfig).
Jól látod, tényleg FailOverChainer osztaly timeout-ját kell állítanod, csak a neve kicsit megtévesztő. Ez a timeout ugyanis nem azt jelenti, hogy ha a cél ennyi ideig nem válaszol akkor tekinti a célt elérhetetlennek (arra ott a lentebbi protokoll, pl TCP), hanem ez azt jeleneti, hogy ha egy cél már nem elérhető, ennyi ideig nem próbálkozik újra. Szóval ha azt akarod, hogy a ha a cél nem elérhető egy darabig ne próbálkozzon, emeled ezt a timeout-ot. Viszont ha a cél visszajön (max) ennyi nem is veszi majd észre.
ok, koszonom, lehet, h trivialis, de Zorp-on belul egy adott proxyra hogy tudom a TCP timeout-ot szabalyozni? Egyalatalan lehet? (vagy absztraktabb szinten: adott protokoll timeoutot szabalyozni egy proxy-ra? Proxynkent mas ertek...? :)) Koszonom: a.
lehet, h trivialis, de Zorp-on belul egy adott proxyra hogy tudom a TCP timeout-ot szabalyozni? Egyalatalan lehet?
egyelőre nem lehet. 3.3-ban majd lesz connect timeout. Péter -- BalaBit IT Bizt. Kft | Tel: +36 1 371-0540 | GnuPG Fingerprint: holtzl.peter@balabit.hu | Mobil: +36 20 366-9667 | 2831 E951 B9EE 63BB F0F4 http://www.balabit.hu/ | Fax: +36 1 208-0875 | 2F4A 1EA4 4B12 7638 29C0
hello,
lehet, h trivialis, de Zorp-on belul egy adott proxyra hogy tudom a TCP timeout-ot szabalyozni? Egyalatalan lehet?
egyelőre nem lehet. 3.3-ban majd lesz connect timeout.
koszonom, meg egy kerdes ezzel kapcsolatban: ugy tudom, hogy a Zorp tobbszalu. Honnan tudja egy ujonnan indulo szal, hogy az egyik back-end nem el? Ezt minden indulaskor ellenorzi, es utana timeoutol? Ha ez igy van, milyen alternativ megoldas letezik, hogy ezt kikuszoboljuk? Kulso programot hivni a proxy indulasakor konfigbol, ami ellenorzi a back-endeket? Koszonom: a.
On Mon, 2007-11-05 at 09:15 +0100, Hegedüs Ervin wrote:
hello,
lehet, h trivialis, de Zorp-on belul egy adott proxyra hogy tudom a TCP timeout-ot szabalyozni? Egyalatalan lehet?
egyelőre nem lehet. 3.3-ban majd lesz connect timeout.
koszonom,
meg egy kerdes ezzel kapcsolatban: ugy tudom, hogy a Zorp tobbszalu. Honnan tudja egy ujonnan indulo szal, hogy az egyik back-end nem el? Ezt minden indulaskor ellenorzi, es utana timeoutol?
Ha ez igy van, milyen alternativ megoldas letezik, hogy ezt kikuszoboljuk? Kulso programot hivni a proxy indulasakor konfigbol, ami ellenorzi a back-endeket?
A chainer feljegyzi, hogy egy adott szerverhez nem sikerult kapcsolodni, a sikertelen kapcsolodas idopontjaval egyutt. Ha egy kovetkezo kapcsolodas ugyanahhoz a szerverhez menne egy adott idon belul, akkor mar nem is probalkozik, rogton a masodikhoz megy. -- Bazsi
Sziasztok,
meg egy kerdes ezzel kapcsolatban: ugy tudom, hogy a Zorp tobbszalu. Honnan tudja egy ujonnan indulo szal, hogy az egyik back-end nem el? Ezt minden indulaskor ellenorzi, es utana timeoutol?
A chainer feljegyzi, hogy egy adott szerverhez nem sikerult kapcsolodni, a sikertelen kapcsolodas idopontjaval egyutt.
Ha egy kovetkezo kapcsolodas ugyanahhoz a szerverhez menne egy adott idon belul, akkor mar nem is probalkozik, rogton a masodikhoz megy.
ezek szerint a chainerbol csak egy peldany van? Vagy egymas kozott kommunikalnak? koszonom: a. -- Minden baj forrása az 1/x függvény.
On Mon, 2007-11-05 at 20:55 +0100, Hegedüs Ervin wrote:
Sziasztok,
meg egy kerdes ezzel kapcsolatban: ugy tudom, hogy a Zorp tobbszalu. Honnan tudja egy ujonnan indulo szal, hogy az egyik back-end nem el? Ezt minden indulaskor ellenorzi, es utana timeoutol?
A chainer feljegyzi, hogy egy adott szerverhez nem sikerult kapcsolodni, a sikertelen kapcsolodas idopontjaval egyutt.
Ha egy kovetkezo kapcsolodas ugyanahhoz a szerverhez menne egy adott idon belul, akkor mar nem is probalkozik, rogton a masodikhoz megy.
ezek szerint a chainerbol csak egy peldany van? Vagy egymas kozott kommunikalnak?
Service-enkent egy peldany. -- Bazsi
participants (3)
-
Balazs Scheidler
-
Hegedüs Ervin
-
HÖLTZL Péter