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

Fri Jul 11 17:50:53 CEST 2014

Hi Albert,

Lieber nach dem Urlaub, stimmt. Du musst mein Repo clonen und dann den branch wechseln:

Git checkout ignore-duplicates

Als config Option taugt das m.E. Nicht weil der Client entscheiden sollte ob er das möchte oder nicht, nicht die Installation.

Wenns kappt fehlt also auch noch eine Anpassung im Logger.

Viele Grüße, Andreas

> Am 11.07.2014 um 17:22 schrieb Albert Dahmen <albert.dahmen at gmail.com>:
> 
> Hallo Andreas,
> 
> ich würde es gerne testen ... allerdings geht es morgen für eine Woche in Urlaub ... und ich bin nicht sicher, ob ich es vorher noch machen soll :-) Aber danach werde ich es direkt ausprobieren! Versprochen :-)
> 
> Aber noch eine vielleicht "dumme" Frage:
> Wie installiere ich die neue Version? Bisher habe ich folgendes gemacht:
> 
>  - dann Backup machen mit "cp -a /var/www/volkszaehler.org
>  /var/www/volkszaehler.org.dist"
>  - jetzt mit "git clone git://github.com/volkszaehler/volkszaehler.org.git
>  /var/www/volkszaehler.org" die aktuelle Version holen
>  - und mit "chown -R www-data /var/www/volkszaehler.org" die Rechte anpassen
> 
> Wie mache ich das jetzt mit dem anderen Zweig? Einfach den Teil hinter git:// anpassen?
> 
> Und noch eine blöde Frage: Wird mit diesem Teil nicht nur die middleware auf einen neuen Stand gebracht? Wenn ja, wie bekomme ich das Update von vzlogger? Das liegt ja in einem anderen Verzeichnis?
> 
> Ist sonst noch was bei einem Test dieser speziellen Version zu beachten?
> Und warum hast Du das mit dem URL-Parameter gemacht und nicht diesen Parameter in die config-Datei aufgenommen?
> 
> VG Albert
> 
> 
> 
> 
> Am 11. Juli 2014 14:05 schrieb Andreas Goetz <cpuidle at gmail.com>:
>> 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/cc8fbc95/attachment.html>