IBM Traveler 9.0.1.16 available

[eknori]

http://www.netzgoetter.net/internet/blogs/netzgoetter.nsf/dx/ibm-traveler-9.0.1.16-available.htm

[Ice-Tee]

Ohne Probleme installiert und läuft bis jetzt fehlerfrei.

[Ice-Tee]

Nun kommt doch eine Frage: In der Nacht wird der Adminserver zwecks Backup täglich heruntergefahren. Danach gelingt es dem Traveler nicht mehr, sich neu zu verbinden. Die Folge ist, das keine Mails mehr gepuscht werden. Nach dem manuellen Neustart des Travelers ist wieder alles ok.
Ist erst seit der neuen Version.
Was könnte das sein?

[eknori]

was sagt denn ein "te traveler status" vor dem traveler neustart?

[Patrick Schneider]

Ein ähnliches Problem habe ich auch. Domino-Server (32 Bit Domino 9.0.1 FP7 mit Traveler 9.0.1.16) wird fürs Backup beendet und danach wieder gestartet, der Domino Mail-Server, auf den per Traveler zugegriffen wird, wird im Anschluss ebenfalls für das Backup später beendet und wieder gestartet.
Morgens bemerkt man, dass der Sync dann nicht mehr funktioniert.

restart task traveler korrigiert das Problem dann aber wieder.

Code

23.02.2017 16:40:02   Traveler: IBM Traveler 9.0.1.16 Build 201702130701_20
23.02.2017 16:40:02   Traveler:    running on IBM Domino server Release 9.0.1FP7 August  17, 2016 on Windows/32 running
on a VM with number of processors of 1
23.02.2017 16:40:02   Traveler:    using maximum database schema 20160812

Also scheint das Problem aufzutreten, wenn der Server, der die Repliken der Maildatenbanken für die Synchronisation beherbergt, für ein paar Minuten nicht verfügbar ist.

Gruß,
Patrick

[Ice-Tee]

Kann ich so bestätigen.
Ich habe als Workaround einen täglichen Neustart des Travelers als Programmtask hinzugefügt. Nicht wirklich schön.

[eknori]

Was sagt denn nun das te traveler status in so einem Fall (VOR dem Neustart des Traveler)?

[Ice-Tee]

Was sagt denn nun das te traveler status in so einem Fall (VOR dem Neustart des Traveler)?

Hallo, ich schau mal ob ich in der nächsten Woche den Autoneustart für einen Tag wieder rausnehme. Dann sag ich dir Bescheid.

[Patrick Schneider]

Was sagt denn nun das te traveler status in so einem Fall (VOR dem Neustart des Traveler)?

Der meldet, dass alles in Ordnung ist. Wenn man auf dem Endgerät einen Sync auslöst, gibt es auch keine Fehlermeldung (weder auf Endgerät noch auf der Konsole des Traveler-Servers), es wird nur nichts Neues synchronisiert.

Code

> tell traveler status
21.02.2017 09:03:41   Traveler: The IBM Traveler task has been running since Mon Feb 20 22:20:23 CET 2017.
21.02.2017 09:03:41   Traveler: The IBM Traveler availability index is currently 100 while servicing 4 users.
21.02.2017 09:03:41   Traveler: 	Database Connection URL: jdbc:derby:ntsdb;create=true.
21.02.2017 09:03:41   Traveler: 	Database Connection Properties: user=APP, clientUser=null, currentLockTimeout=null, loginTimeout=null.
21.02.2017 09:03:41   Traveler: The last successful device sync was on Tue Feb 21 09:02:41 CET 2017.
21.02.2017 09:03:41   Traveler: The overall status of IBM Traveler is Green.

Gruß,
Patrick

[Tannibal]

Wir haben das Verhalten auch ab und zu - unabhängig von der Traveler-Version. 

[Ice-Tee]

Wir haben das Verhalten auch ab und zu - unabhängig von der Traveler-Version. 

Na ja, mit der aktuellen Version ist es aber nicht nur ab und zu. Das ist permanent.

[shiraz]

Das Problem haben wir auch, aber nach Update auf FP 16.

[Ice-Tee]

Ja, das scheint ein Bug zu sein. Immer mehr User berichten davon: "User didn´t receive no more mails. With a "tell traveler user %USERNAME%" you can see that the Monitoring for the database is "disabled". After restart of Traveler all fine and also the Monitor Status will change to "enabled"."

[LionKing]

Wir sind von dem Problem wohl auch betroffen. Unsere Server werden zwar nachts nicht heruntergefahren aber trotzdem bricht der Sync quasi einmal täglich ab und der Traveler muss neu gestartet werden. Hoffentlich bringt IBM da bald einen Fix.

[hallo.dirk]

Wir sind von dem Problem wohl auch betroffen. Unsere Server werden zwar nachts nicht heruntergefahren aber trotzdem bricht der Sync quasi einmal täglich ab und der Traveler muss neu gestartet werden. Hoffentlich bringt IBM da bald einen Fix.

Schon einen PMR aufgemacht?

[LionKing]

Schon einen PMR aufgemacht?

Ja.

[Pfefferminz-T]

Bitte auf keinen Fall die PMR-Nummer hier reinschreiben, sonst könnten sich noch andere betroffene Firmen an den PMR anhängen und die Priorität des PMR bei der IBM erhöhen.

[Micha B]

Mir ist das anders bekannt, jede Problemeröffnung generiert eine eigene Problem Nummer. Als Firma ABC kannst Du nicht mit Problemtickets der Firma XYZ arbeiten oder deren Priorität erhöhen.

[schroederk]

Mir ist das anders bekannt, jede Problemeröffnung generiert eine eigene Problem Nummer. Als Firma ABC kannst Du nicht mit Problemtickets der Firma XYZ arbeiten oder deren Priorität erhöhen.

Ist mir auch so bekannt.

Bitte auf keinen Fall die PMR-Nummer hier reinschreiben, sonst könnten sich noch andere betroffene Firmen an den PMR anhängen und die Priorität des PMR bei der IBM erhöhen.

Wenn sich tatsächlich mehrere betroffene Firmen anhängen und damit die Priorität erhöhen könnten, dann wäre es imho sogar sinnvoll, wenn sich die Prio erhöht und das Problem schneller gelöst wird.


Insgesamt sehe ich das Problem mit der neuen Version eher als nicht so furchtbar wichtig. Diejenigen, die sich keine Domino-taugliche Datensicherung leisten wollen und ohnehin den Mailserver zeitgesteuert runterfahren und wieder neustarten, die können auch gerade den Traveler-Task neustarten. Wenn mal nachts für 20 Sekunden keine Mails auf das Smartphone kommen, finde ich das weniger problematisch als ein Mailserver, der womöglich für ein paar Stunden nur wegen einem Backup offline ist. (Was passiert mit Mails, die während der Offline-Zeit zugestellt werden sollten? Was passiert wenn der Cluster während des Backups auch offline geht?)

[hallo.dirk]

Na ja, es macht die Eröffnung des Ticktes einfacher, wenn man auf ein anderes verweisen kann .

Ausserdem würde es dann Identische Sachbearbeiter sein, und der eskaliert dann