[vz-users] Massive Probleme ... vzlogger läuft nicht mehr ...

[Andreas Goetz]

Hallo Zusammen,

ich habe hier mal einen Bastelzweig eröffnet:
https://github.com/andig/volkszaehler.org/tree/master-ignore-duplicates

Darin gibts zwei wesentliche Änderungen:
- statt ORM wird jetzt mittels SQL in die DB geschrieben- das könnte einen
Performancezuwachs bringen (nicht getestet)
- Duplikate werden bei JSON requests wie der Logger sie macht jetzt immer
ignoriert (nicht konfigurierbar)

Viel Spass beim Testen!

vg
Andreas



2014-07-07 12:09 GMT+02:00 Andreas Goetz <cpuidle at gmail.com>:

> Hi Thomas,
>
> 2014-07-07 11:52 GMT+02:00 <thomas at gauweiler.org>:
>
> Hallo Andreas,
>>
>> na, man sollte schon beim ersten Problem anpacken.
>> z.B. sollte man den Timeout des vzloggers größer machen, als den der
>> Middleware beim Bearbeiten eines Request.
>>
>
> Klar- aber auch da muss im logger gehandelt werden. Letzlich ist das aber
> nur Linderung da durch Lastsituationen sowas prinzipiell immer auftreten
> kann, oder?
>
>
>> Dadurch sollte dieser Zustand nicht mehr auftreten, denn wenn die
>> Middleware kein Commit mehr machen kann, sind die Daten nicht drin.
>> (macht die MW eigentlich Masseninsert mit abschliessendem Commit wird
>> jeder Insert einzeln Committed?)
>>
>
> 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.
>
>
>>
>> Dann hast du aber natürlich recht: nach einem timeout sollte der vzlogger
>> die alten Daten nur unter Vorbehalt noch mal schreiben.
>> Am besten wenn er das der MW im Request mitteilen kann. Dann könnte die MW
>>
>
> 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.
>
>
>> noch bei so einer DB-Meldung prüfen, ob sie tatsächlich die gleichen Daten
>> noch mal schreiben will. Da der neue Request vom vzlogger dann alte und
>> neue Daten umfasst, muss man das auch Satzweise prüfen...
>>
>
> Ehrm. Genau- gleicher Gedanke ;)
>
>>
>> Hab leider auch zu wenig Zeit um mich in den SourceCode von vzlogger und
>> MW einzuarbeiten, sonst würde ich da gerne helfen.
>> Mit welchen Tools wird da eigentlich entwickelt? Doch nicht Editor und
>> Make, oder? Kann mir jemand beschreiben, wie ich einen Debugger auf
>> vzlogger bzw. auf die MW ansetze?
>>
>
> Vmtl. Rainer?
>
>
>>
>> LG Thomas.
>>
>
> vg
> Andreas
>
>
>>
>>
>> On Mon, 7 Jul 2014 11:27:55 +0200, Andreas Goetz <cpuidle at gmail.com>
>> wrote:
>> > Moin Thomas,
>> >
>> > 2014-07-07 11:19 GMT+02:00 <thomas at gauweiler.org>:
>> >
>> >> Das ist doch "nur" das Folgeproblem. Das eigentliche Problem ist ein
>> >> Kommunikationsproblem:
>> >> vzlogger bricht einen HTTP-Request mit timeout ab, während die
>> >> Middleware
>> >> den Request noch fertig bearbeitet.
>> >>
>> >
>> > Warum auch immer, ja.
>> >
>> >
>> >> Jetzt stehen die Daten in der DB aber vzlogger meint, dass sie noch
>> nicht
>> >> drin sind.
>> >> Und erst beim nächsten Versuch des vzloggers kommt es dann zur
>> >> DB-Meldung,
>> >> dass dieser Zeitstempel schon in der DB steht.
>> >>
>> >
>> > Genau. Aber worauf willst Du hinaus? Letzlich kann nur der Logger wissen
>> ob
>> > oder dass es "safe" ist die Daten jetzt zu verwerfen. Einem anderen
>> Client
>> > bzw. dem Anwender muss die MW solche Meldungen sehrwohl präsentieren.
>> >
>> > Grüße, Thomas
>> >>
>> >
>> > Oder worin besteht Dein Vorschlag?
>> >
>> > vg
>> > Andreas
>> >
>> >
>> >>
>> >> On Sun, 6 Jul 2014 22:40:50 +0200, Andreas Götz <cpuidle at gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > An der Fehlermeldung der MW?
>> >> >
>> >> > Woher soll den umgekehrt die MW wissen welche App problematisch ist
>> so
>> >> > dass sie deren Daten verwerfen soll ohne Fehlermeldung?
>> >> >
>> >> > M.e. Gehört das in den Logger.
>> >> >
>> >> > Viele Grüße,
>> >> > Andreas
>> >> >
>> >> >> Am 06.07.2014 um 22:04 schrieb Udo1 <udo1 at gmx.net>:
>> >> >>
>> >> >> Am 06.07.2014 16:27, schrieb Andreas Götz:
>> >> >>> Wäre es evtl sinnvoll vzlogger die Möglichkeit zu geben
>> insbesondere
>> >> >>> bei DB Integrity Constraint Fehlern eine bestimmte Anzahl von
>> >> >>> Datensätzen zu verwerfen?
>> >> >> Wie soll vzlogger solche "DB Integrity Constraint Fehler" erkennen?
>> >> >> Das
>> >> >> ist doch ein Datenbank-Problem. Oder sehe ich das falsch?
>> >> >>
>> >> >> Gruß
>> >> >> Udo
>> >>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20140708/6e564c63/attachment.html>