avanti-* timeout

[Thomas Berger]

Lieber Herr Eger,

> in der Konfiguration des Windows- als auch des *N?X-Avantis
> kann man einen Timeout einstellen, der lt. Beschreibung
> einen Abbruch des Auftrages steuert.
> 
> Der ist so o.k.

Es ist ein Timeout (Alarm) in realen Sekunden, d.h.
laufen zwei Jobs gleichzeitig, so steht beiden nur
die halbe normale CPU-Zeit zur Verfuegung, bevor der
Alarm zuschlaegt. Das ist vertretbar, weil sich das
System damit vor Ueberlastung schuetzt (avanti-x ist
extrem langsam, fuer grosse Recherchen muss man hier
selbst auf dicken Sun's mit 120 Sekunden rechnen beim
SR-Expandieren von Ergebnismengen im 4stelligen Bereich
oder beim Anwenden von Restriktionen, liefen 5 Jobs
gleichzeitig, kaeme ein nach CPU-Zeit berechneter Abbruch
erst nach 10 Minuten, bis dahin haetten die Anwender
alle schon zweimal auf "Reload" gedrueckt...

 
> Der "innere" Timeout von Avanti verursacht mir aber immer noch
> Ärger.
> 
> Die Avanti-x-Version vom 10.12.2002 startet die Bearbeitung eines
> Jobs nach ca. 3 s automatisch , auch wenn noch kein "AVANTI:EOJ"
> eingetroffen ist.

Ich habe letzte Woche "Dr. Avanti" um testweise frei
zu waehlende Zwangspausen zwischen Jobzeilen ergaenzt,
als ich behauptet hatte, auch avanti-x wuerde nach dem ersten
Empfangenen TCP-Paket losrechnen. Ich habe dabei auch
bemerkt, dass es immer dann losrechnet, wenn ca. 3 Sekunden
nach dem letzten empfangenen Paket verstrichen sind.

 
> Diese Zeit ist jedoch für den praktischen Einsatz viel zu kurz.

In Weitverkehrsnetzen wuerde man eher in Groessenordnungen
von 60 oder 120 Sekunden rechnen. Problematisch ist aber,
dass avanti-x nicht abbricht, sondern den partiell
empfangenen Job (der ja keine Datenbankkennung etc.
enthaelt) ausfuehrt. Noch problematischer ist, dass es
die dann doch noch ankommenden Zeilen des urspruenglichen
Jobs als eigene Jobs ausfuehrt, das gibt natuerlich nur
noch Salat. Wenn also ein Verbindungs-Timeout existiert
(zusaetzlich zum Rechenzeit-Timeout), so sollte Ueberschreiten
stets zum Abbrechen der Verbindung fuehren, alles andere
ist sinnlos und auch schaedlich. Ich vermute, dass dieses
3-Sekunden-Feature eingebaut wurde, als AVANTI:EOJ nachtraeglich
eingefuehrt wurde, kann mir aber nicht vorstellen, dass
irgendwelche Anwender mit einer eingebauten 3-sekuendigen
Verzoegerung haben leben wollen. Ausserdem hat avanti-w
dieses "Feature" nie gehabt.

> 1. Gibt es für die .avanti-Datei einen Parameter,
>    der diese Timeout-Dauer steuert?
> 
> 2. Wenn nicht, plädiere ich dafür, einen solchen einzuführen
>    und/oder das Verhalten des avanti so zu verändern, dass nach
>    dem Timeout OHNE AKTION mit einer Fehlermeldung abgebrochen wird.

unbedingt!

 
> Hintergrund:
> 
> 3 s Verzögerung werden schnell erreicht, wenn in einem Netzwerk
> mehrere Nutzer zur gleichen Zeit auf die Idee kommen, eine größere
> Word-Datei zu öffnen oder eine Kopieraktion anschieben.
> Ich habe Netze kennengelernt, in denen an die 100 PC "zu sehen"
> sind und gleichzeitig restriktive Sicherheitsbeschränkungen
> gelten. Wenn dann der Avantiserver auch nur über eine Firewall
> angesprochen werden muss, gleichzeitig aber 50 Leute auf die
> Idee kommen, den Browser zu starten, dann passiert auch mal 10 s
> nichts.

Das ist aber furchtbar. Wenn es auf Netzwerkniveau bereits
zu Verzoegerungen von mehr als 100ms kommt, sollte man
sich lieber ein anderes Konzept ausdenken. In Ihrer
Situation hat ja der Webserver es irgendwie geschafft,
50 mal das CGI-Skript zu starten, das nun jeweils gemuetlich
Jobs uebertraegt. In dieser Situation ist das Skript aber
nicht viel langsamer als ein compiliertes Programm, halbwegs
genug Arbeitsspeicher vorausgesetzt. 10 Sekunden 
Verzoegerung waeren dann also durch Netzueberlast oder
Firewall verursacht. (Wenn es natuerlich um Timeouts bei der 
*Antwort* von Avanti geht, ist es eine andere Sache.
Das sollten aber Timeouts sein, die im CGI-Skript oder
sonstigen Avanti-Client realisiert sind, in Avanti hoechstens
als 600 Sekunden: Wenn solange der Buffer nicht geleert
werden konnte, ist die Verbindung wohl zusammengebrochen,
ohne dass der Kommunikationsteil das konstatiert hat...)

 
> Das zu verkraften, sollte Avanti ermöglichen. Die falscheste
> Reaktion ist es meiner Meinung nach, einen halb empfangenen Job
> zu bearbeiten.

Unbedingt.
 
> Ich finde den bisher verwendbaren "workaround", zuerst an's Ende
> und von dort wieder an den Anfang springen zu lassen (das provo-
> ziert bei unvollständigen Jobs einen Abbruch), einfach unschön.

aber originell!

viele Gruesse
Thomas Berger