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

[Andreas Goetz]

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/20140707/aee00b3e/attachment.html>