<div dir="ltr">Hi Thomas,<br><div class="gmail_extra"><br><div class="gmail_quote">2014-07-07 11:52 GMT+02:00  <span dir="ltr"><<a href="mailto:thomas@gauweiler.org" target="_blank">thomas@gauweiler.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo Andreas,<br>
<br>
na, man sollte schon beim ersten Problem anpacken.<br>
z.B. sollte man den Timeout des vzloggers größer machen, als den der<br>
Middleware beim Bearbeiten eines Request.<br></blockquote><div><br></div><div>Klar- aber auch da muss im logger gehandelt werden. Letzlich ist das aber nur Linderung da durch Lastsituationen sowas prinzipiell immer auftreten kann, oder?<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dadurch sollte dieser Zustand nicht mehr auftreten, denn wenn die<br>
Middleware kein Commit mehr machen kann, sind die Daten nicht drin.<br>
(macht die MW eigentlich Masseninsert mit abschliessendem Commit wird<br>
jeder Insert einzeln Committed?)<br></blockquote><div><br></div><div>Ich vermute vzlogger übergibt die Daten per JSON statt mittels einzelner Requests? Dann gibts auch den Commit nur einmal. Wenns da Befindlichkeiten bzgl. Performance gibt müsste mir jemand mal einen SQL Trace schicken da ich keinen vzlogger habe.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dann hast du aber natürlich recht: nach einem timeout sollte der vzlogger<br>
die alten Daten nur unter Vorbehalt noch mal schreiben.<br>
Am besten wenn er das der MW im Request mitteilen kann. Dann könnte die MW<br></blockquote><div><br></div><div>Das wäre auch eine Variante. Einer muss die Probleme halt aussortieren. Entweder der vzl schaut anhand der Fehlermeldung welcher Timestamp problematisch war (und muss das ggf. mehrfach machen) oder er sagt der MW "nimm halt was geht"- aber z.B. erst bei einem Retry. Die Variante gefällt mir ganz gut da sie sich auch für vzclient anbieten würde. Muss ich mal recherchieren.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
noch bei so einer DB-Meldung prüfen, ob sie tatsächlich die gleichen Daten<br>
noch mal schreiben will. Da der neue Request vom vzlogger dann alte und<br>
neue Daten umfasst, muss man das auch Satzweise prüfen...<br></blockquote><div><br></div><div>Ehrm. Genau- gleicher Gedanke ;) <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Hab leider auch zu wenig Zeit um mich in den SourceCode von vzlogger und<br>
MW einzuarbeiten, sonst würde ich da gerne helfen.<br>
Mit welchen Tools wird da eigentlich entwickelt? Doch nicht Editor und<br>
Make, oder? Kann mir jemand beschreiben, wie ich einen Debugger auf<br>
vzlogger bzw. auf die MW ansetze?<br></blockquote><div><br></div><div>Vmtl. Rainer?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
LG Thomas.<br></blockquote><div><br></div><div>vg<br></div><div>Andreas<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Mon, 7 Jul 2014 11:27:55 +0200, Andreas Goetz <<a href="mailto:cpuidle@gmail.com">cpuidle@gmail.com</a>><br>
wrote:<br>
<div class="HOEnZb"><div class="h5">> Moin Thomas,<br>
><br>
> 2014-07-07 11:19 GMT+02:00 <<a href="mailto:thomas@gauweiler.org">thomas@gauweiler.org</a>>:<br>
><br>
>> Das ist doch "nur" das Folgeproblem. Das eigentliche Problem ist ein<br>
>> Kommunikationsproblem:<br>
>> vzlogger bricht einen HTTP-Request mit timeout ab, während die<br>
>> Middleware<br>
>> den Request noch fertig bearbeitet.<br>
>><br>
><br>
> Warum auch immer, ja.<br>
><br>
><br>
>> Jetzt stehen die Daten in der DB aber vzlogger meint, dass sie noch<br>
nicht<br>
>> drin sind.<br>
>> Und erst beim nächsten Versuch des vzloggers kommt es dann zur<br>
>> DB-Meldung,<br>
>> dass dieser Zeitstempel schon in der DB steht.<br>
>><br>
><br>
> Genau. Aber worauf willst Du hinaus? Letzlich kann nur der Logger wissen<br>
ob<br>
> oder dass es "safe" ist die Daten jetzt zu verwerfen. Einem anderen<br>
Client<br>
> bzw. dem Anwender muss die MW solche Meldungen sehrwohl präsentieren.<br>
><br>
> Grüße, Thomas<br>
>><br>
><br>
> Oder worin besteht Dein Vorschlag?<br>
><br>
> vg<br>
> Andreas<br>
><br>
><br>
>><br>
>> On Sun, 6 Jul 2014 22:40:50 +0200, Andreas Götz <<a href="mailto:cpuidle@gmail.com">cpuidle@gmail.com</a>><br>
>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > An der Fehlermeldung der MW?<br>
>> ><br>
>> > Woher soll den umgekehrt die MW wissen welche App problematisch ist<br>
so<br>
>> > dass sie deren Daten verwerfen soll ohne Fehlermeldung?<br>
>> ><br>
>> > M.e. Gehört das in den Logger.<br>
>> ><br>
>> > Viele Grüße,<br>
>> > Andreas<br>
>> ><br>
>> >> Am 06.07.2014 um 22:04 schrieb Udo1 <<a href="mailto:udo1@gmx.net">udo1@gmx.net</a>>:<br>
>> >><br>
>> >> Am 06.07.2014 16:27, schrieb Andreas Götz:<br>
>> >>> Wäre es evtl sinnvoll vzlogger die Möglichkeit zu geben<br>
insbesondere<br>
>> >>> bei DB Integrity Constraint Fehlern eine bestimmte Anzahl von<br>
>> >>> Datensätzen zu verwerfen?<br>
>> >> Wie soll vzlogger solche "DB Integrity Constraint Fehler" erkennen?<br>
>> >> Das<br>
>> >> ist doch ein Datenbank-Problem. Oder sehe ich das falsch?<br>
>> >><br>
>> >> Gruß<br>
>> >> Udo<br>
>><br>
</div></div></blockquote></div><br></div></div>