Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.03.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
> [Multiserver-Netcall]
>> Da mu� man sich dann allerdings nochmal genau ansehen, wie man das
>> Unversandt-Handling sauber hinbek�me. Das wird nicht ganz trivial.
> F�r mich w�re es glatter overkill.
Richtig, ich wollte ja nur aufzeigen, was gemacht werden k�nnte/m��te.
Schon beim Kopieren der Dateien ins UKA_PPP-Spool fangen die Probleme
wegen der identischen Dateinamen ja an, wie mir dann sp�ter noch
eingefallen ist.
> Das Hauptproblem sehe ich eigentlich nur darin, da� die Abarbeitung
> nicht f�r jede Box separat von XP angesto�en wird, weil sonst die
> Pausen beim Einlesen st�ren
Da wird's beizeiten noch eine �nderung geben, da� alle Nachrichten ganz
am Schlu� in einem Rutsch eingelesen werden. Thomas hat das mal zu
Recht moniert.
> und daher die Nachrichten immer noch unversandt erscheinen.
Nee, das nun nicht (wenn es korrekt gemacht wird).
> [...]
>> Ach so, jetzt ist klar - wenn Du die MID per Filter patchst, wirst
>> Du diesbzgl. allerdings Probleme bekommen. Vermutlich wird das
>> Ergebnis sein, da� eine Nachricht mit gepatchter MID, die nicht
>> versandt werden konnte, von XP als versandt betrachtet werden wird.
>> Und zu der MID, die die unversandte Nachricht inzwischen tr�gt, wird
>> XP keine Nachricht in der Datenbank finden und mit einer
>> Fehlermeldung reagieren.
> Nichts da, es erscheint lediglich die Meldung da� nicht alle
> Nachrichten versandt werden konnten
Ist ja auch eine Fehlermeldung. IIRC (hab's nicht getraced jetzt) f�hrt
die pure Existenz von *.OUT im Spool erstmal zu dieser Meldung. Da�
eine Nachricht wegen gepatchter MsgID anschlie�end gar nicht gefunden
und zum erneuten Versand bereitgestellt werden kann, wird dann nicht
mehr gesondert bem�ngelt.
Was sollte XP mit dieser Nachricht auch sonst anfangen?
> und dennoch sind die unversandten nicht mehr markiert und das
> <box>.pp-File ist gel�scht.
Auch klar. Nur wenn eine oder mehrere *.OUT im Spool liegen, die eine
in der Datenbank existierende MsgID haben, wird bei diesen das
Unversandt-Flag nicht entfernt und sie in einem neu generierten <Box>.PP
zum erneuten Versand bereitgestellt.
>> Stimmt, ist ein Szenario, mit dem man das Unversandt-Handling
>> sabotieren kann.
> Und sehr effektiv, ist aber der klassische Fall, da� mit
> Ausgangsfiltern nicht zu spa�en ist..
Jup, evtl. sollte man vor dem Patchen von MsgIDs sogar nochmal gesondert
warnen.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
