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

[Andreas Goetz]

Hallo,

jetzt wärs natürlich auch cool wenns mal jemand testen würde :/

https://github.com/andig/volkszaehler.org/tree/ignore-duplicates

Ich hab das Verhalten jetzt konfigurierbar gemacht- einfach
options=skipduplicates an die URL anhängen, dann werden die ignoriert.
zusätzlich wird jetzt immer rows=xyz ausgegeben woran man erkennen kann
wieviele Datensätze tatsächlich eingefügt wurden.
Prinzipiell nutzen wir jetzt immer plain SQL, es sollte also auch noch
schneller werden...

vg
Andreas


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

> 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/20140711/6ecc5363/attachment-0001.html>