Scheduler friert ein

[Pluto]

Moin!

Ich nutze die 3.x Business-Version und will eine ganzen Flotte (ca.15) von Notebooks mit bestimmten Daten eines Servers aktualisieren.
Für jedes NB habe ich ein eigenes Profil angelegt, für jedes Profil möchte ich gerne einen eigenen Task im Scheduler anlegen.

Dazu habe ich im Scheduler die Task-Art "Verbindung" gewählt etc.

Bei nur einem derartigen Task funzt alles perfekt.
Lege ich aber einen zweiten, gleichartigen, Task an, der eben ein weiteres Notebook bei Verbindung mit dem LAN aktualisieren soll, friert mir der Scheduler ein, er wird sehr sehr langsam.
Sollte ich es dennoch mit viel Geduld und Zeit schaffen, einen weitern Task anzulegen und den Scheduler zu aktivieren, so läuft alles einwandfrei.
Über einen 3. Task in dieser Art brauche ich gar nicht erst nachdenken.....

Die CPU-Last und Speicherauslasung ist übrigens sehr gering, es scheint mir eher ein Konflikt inder Verbindungsüberwachung zu den temporären Clients zu sein...

Ist o.g. Vorhaben mit AllSync überhaupt möglich oder ziehe ich das grundsätzlich verkehrt auf?

Es gibt bestimmt eine einfache Lösung

[Administrator]

Nach Ihrer Beschreibung zu urteilen könnte die Überprüfung der Verbindung dieses längere "Einfrieren" auslösen. Anscheinend existiert bei Ihnen auf dem Rechner ein längeres Systemtimeout, bis die Überprüfung beendet wird, falls der Netzwerkordne rnicht existiert. Oder existieren die Verbindungsordner beim anlegen der Tasks?

[Pluto]

Nein- die Netzwerkordner existieren beim Anlegen der Tasks nicht.
Ihr Frage zielt wahrscheinlich darauf ab, daß alleine das Anlegen der Tasks (genauer: ab dem 2. Task) dann schon im Scheduler sehr lange dauert?

Ich hatte es allerdings auch schon mal geschafft 3 derartige Tasks anzulegen. Aber auch wenn schon eigige Tasks im Scheduler existieren ist dieser sehr sehr langsam - auch nach enem Restart.

Wo kann ich denn in einem XP-Server die Timeout-Einstellungen sehen bzw. ändern?

[Pluto]

Ich habe das Prob noch einmal auf einer Testmaschine in einem kleinen Test-LAN gecheckt:
Läuft alles flott!

Es fällt auf, daß im Scheduler in der Statusleiste die Meldung "Verbindung zu xxx wird geprüft" (sinngemäß) nur sehr kurz aufblitzt.

In meinem Workframe in der Firma (also dort, wo o.g. Prob auftritt) steht für jeden Task mindestens für 2 Minuten obige Status-Meldung an, bevor dann auf den näschten Task (wieder für mind. 2 Minuten) gewechselt wird.

Das Prob scheint datsächlich die Netztwerkkonfiguration zu sein, da diese sehr lange für den "Verbindungscheck" braucht. Wo und wie man dieses "Antwort-Zeit-Verhalten" beim Verbindungscheck konfiguriert weiß ich (noch) nicht, werde mich aber intensiev darum kümmern.

Vielleicht hat aber der Support von AllSync schon eine Antwort?

[Administrator]

Sie können das Timeout-Problem beim Anlegen der Tasks umgehen, indem Sie nach dem Erstellen eines Tasks diesen in der Liste deaktivieren. Dadurch wird dann im Hintergrund keine Überprüfung mehr durchgeführt.

Zur Überprüfung ob ein Ordner existiert wird die interne Standardfunktion "FindFirstFile" von Windows verwendet. Googlen Sie mal nach "FindFirstFile timeout". Dann werden Sie noch mehr Infos dazu bekommen.

[Pluto]

Ja - so geht's erst einmal
Da AllSync bei uns auf einem exklusievem Virtuellen Server läuft könen wir das so machen.

Danke noch einmal für den Support

[Pluto]

...schnell mal gegoogled und

- Problemursache gefunden und erklärt
- Problemlösung unter Nutzung dieser Funktion offensichtlich nicht möglich

Vielleicht setzen die Entwickler von AllSync dieses Prob auf die ToDo- Liste für die nächste Version? (bitte bitte)

[Administrator]

Was für eine Problemlösung mit einer anderen Funktion haben Sie gefunden?

[Pluto]

Mißverständnis:

Ich habe KEINE wirkliche LÖSUNG des Probs gefunden.
Der Workaround, den Sie weiter oben beschrieben haben, läßt den Einsatz mehrer Tasks mit der Startart "Verbindung" in einem WAN zu.
Allerdings mit einer grausam langsamen Performance. Nicht etwa im Datentransfer der Synchrinisation (die ist perfekt), sondern die ganze Anwendung friert förmlich ein, wird sehr sehr langsam.

Die URSACHE des Probs scheint in der Verwendung der Windows-Funktion "FindFirstFile()" zu liegen, die AllSync verwendet.
Im INet gibt es eine Fülle von Userberichten, die genau das o.g. Problem (lange Timeouts bei der Verbindungsprüfung) unter Verwendung von FindFirstFile() beschreiben. Allerdings scheint der Aufruf der Funktion keine Übergabe von derart dezidierten Parametern wie z.b. die Timeouts vorzusehen.

Ich erlaube mir als USER jetzt einfach mal das Fazit, das AllSync bei der von mir verwendeten Einsatzart erhebliche Schwächen aufzeigt. Ich kann mir vorstellen, daß die Entwickler von AllSync als Bussiness/Enterprise- Anwendung das nur ungern auf sich sitzen lassen wollen und nach einer Lösung in einer der nächsten Versionen/Updates suchen werden.
Entweder man kann die API FindFirstFile() impfen (vermutlich geht das aber nur mit eine Änderung der abhängigen DLL) oder man bedient sich einer anderen Methode der Verbindungsprüfung.

Einen Hinweis zur Milderung des Probs habe ich noch gefunden und gebe ich hier gerne weiter:
DNS-Server im LAN/WAN so einrichten, daß dieser bei schlussendlich erfolglosem Aufruf des UNC-Namens (Clients) KEINE Default IP zurück gibt. Das spart Zeit!