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

[Andreas Goetz]

Hallo Albert,

2014-07-21 21:16 GMT+02:00 Albert Dahmen <albert.dahmen at gmail.com>:

> Nachdem ich nun aus dem Urlaub zurück bin würde ich gerne in den Test
> einsteigen.
>

Die Lösung ist fertig und wurde von Thomas schon erfolgreich getestet.


> Da ich mich aber leider mit GIT absolut nicht auskenne brauche ich ein
> wenig Hilfe :-)
>
> Was genau muss ich machen?
>

Eigentlich nichts. Was wir wirklich brauchen ist jemanden der den vzlogger
so anpasst dass das neue Feature auch verwendet werden kann. Leider gabs
von den Entwicklern kein Feedback- insofern ruht das Thema bis sich jemand
findet.

Ich kanns leider nicht lösen.

vg
Andreas


>
> VG Albert
>
>
> Am 11. Juli 2014 17:50 schrieb Andreas Götz <cpuidle at gmail.com>:
>
> 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/20140723/fa3e83db/attachment-0001.html>