1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Auf Github: Telekom und SAP…

Rein geguckt, 3 schwere threading Bugs gemeldet

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: twothe 01.06.20 - 03:15

    Scheint mir wieder so eine SAP Qualitätssoftware zu sein...

  2. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: h31nz 01.06.20 - 10:20

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Scheint mir wieder so eine SAP Qualitätssoftware zu sein...

    Hab mir gerade alle Issues der Android- und ios-App angeguckt. Da gibt es kein einziges Issue über Threading-Bugs. Wieso denkst du dir sowas aus?

  3. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: Panzergerd 01.06.20 - 10:42

    Er meint die beiden. Die betreffen allerdings nicht die Apps, sondern den Server der schon vorher veröffentlicht wurde:
    https://github.com/corona-warn-app/cwa-server/issues/398
    https://github.com/corona-warn-app/cwa-server/issues/399

  4. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: twothe 01.06.20 - 12:34

    Panzergerd schrieb:
    --------------------------------------------------------------------------------
    > Er meint die beiden. Die betreffen allerdings nicht die Apps, sondern den
    > Server der schon vorher veröffentlicht wurde:
    > github.com
    > github.com

    Korrekt. Du Stalker! :P

  5. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: Peter V. 01.06.20 - 12:53

    Also er meint die beiden drei "schweren" Fehler der App, die beim Server auftreten. Gut, dass wir das geklärt haben. Und mit Qualitätssoftware kennt sich twothe offensichtlich aus.



    1 mal bearbeitet, zuletzt am 02.06.20 08:04 durch sfe (Golem.de).

  6. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: twothe 01.06.20 - 13:27

    Tut er.

  7. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: OtherOne 01.06.20 - 13:29

    Die "Bugs" sind weder schwere Threading Bugs, noch sind es 3. Das einzige, was evtl. zu Problemen führen könnte ist der commonPool und selbst das ist auf jeden Fall kein schwerwiegender Threading-Bug, sondern kann unter Umständen zu Problemen führen, wenn jemand an anderer Stelle Unsinn fabriziert.

    Das ist mal wieder ein typischer Fall von Schlechtmacherei, denn insgesamt sieht das Projekt ziemlich vernünftig aus Und die Ausdrucksweise ist auch ziemlich toxisch. Wenn man die Lösung schon weiß, stellt man auch einen Pull Request und gut und tönt nicht im Golem Forum herum. Das auch noch mit Klarnamen zu machen...

  8. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: smonkey 01.06.20 - 13:29

    Peter V. schrieb:
    --------------------------------------------------------------------------------
    > Also er meint die beiden drei "schweren" Fehler der App, die beim Server
    > auftreten.

    +1

  9. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: WalterSobchak 01.06.20 - 19:59

    OtherOne schrieb:
    --------------------------------------------------------------------------------
    > Die "Bugs" sind weder schwere Threading Bugs, noch sind es 3. Das einzige,

    Warum Bugs in Anführungszeichen?
    Es sind klassische MT Fehler, die dürfen bei SAP einfach nicht passieren.
    Ich würde sagen in Falle von MT gibts überhaupt keine nicht schweren Bugs. Alle Bugs dort sind schwer, weil sie irgendwo im Programm dann Probleme bereiten, wie Du ja auch selber zugibst (wenn jemand an andere Stelle Unsinn fabriziert). Also einer kann Unsinn fabrizieren, aber wenn es zwei machen kann das schon zu erheblichen Problemen führen. Und was ist schon ein bisschen Server Stillstand...

  10. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: twothe 02.06.20 - 00:45

    Um die Bugs mal zu erläutern:

    Es wird im inner-loop des Servers mehrfach synchronized verwendet, aber nicht auf ein lokales Objekt sondern auf die Klasse selbst. D.h. der ganze Server würde bei Last kaum mehr als 1 CPU verwenden können, da ständig auf synchronized Blöcke gewartet werden muss. Generell kann man sagen: wenn in Server-Code das Wort synchronized auftaucht, dann ist das ein Programmierfehler.

    In einem threaded-Server einen Thread zu starten macht nur dann Sinn, wenn man parallel langläufige blockende Operationen hat. In allen anderen Fällen erreicht man keine bessere Performance sondern macht die Sache nur noch schlimmer, weil ein Server eben nur X CPUs hat. Und wenn die ausgelastet sind dann sind die ausgelastet, weitere Anfragen können dann schlicht nicht angenommen werden oder führen zu timeouts.

    Die Verwendung des common ForkJoinPools hat 2 Probleme: einerseits wird dieser auch von Streams verwendet, d.h. wenn der Server-Thread irgendwo einen parallel Stream starten will, kann das unter Last zu einem Dead-Lock führen, da dann der Thread im ForkJoinPool auf einen freien Thread im selben ForkJoinPool warten muss.

    Außerdem würde der Pool unter Last irgendwann keine weiteren Tasks mehr annehmen weil er voll ist und submit würde eine Exception werfen. D.h. durch die Idee etwas in einen Thread auszulagern hat man stattdessen nur eine 500-Quelle unter Laste eingebaut.

    Und dann sind da noch die vielen kleinen Probleme, wie beispielsweise das ein DeferredResult benutzt wird, obwohl eigentlich ein CallableFuture benutzt werden sollte, der intern übrigens aus Threading-Sicht gruselig programmiert ist, oder das der ForkJoinPool für die Aufgabe der völlig falsche Executor ist.

    In der Summe: da hat ein Anfänger dran gesessen.

  11. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: OtherOne 02.06.20 - 09:20

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Um die Bugs mal zu erläutern:
    >
    > Es wird im inner-loop des Servers mehrfach synchronized verwendet, aber
    > nicht auf ein lokales Objekt sondern auf die Klasse selbst. D.h. der ganze
    > Server würde bei Last kaum mehr als 1 CPU verwenden können, da ständig auf
    > synchronized Blöcke gewartet werden muss. Generell kann man sagen: wenn in
    > Server-Code das Wort synchronized auftaucht, dann ist das ein
    > Programmierfehler.
    >
    > In einem threaded-Server einen Thread zu starten macht nur dann Sinn, wenn
    > man parallel langläufige blockende Operationen hat. In allen anderen Fällen
    > erreicht man keine bessere Performance sondern macht die Sache nur noch
    > schlimmer, weil ein Server eben nur X CPUs hat. Und wenn die ausgelastet
    > sind dann sind die ausgelastet, weitere Anfragen können dann schlicht nicht
    > angenommen werden oder führen zu timeouts.
    >
    > Die Verwendung des common ForkJoinPools hat 2 Probleme: einerseits wird
    > dieser auch von Streams verwendet, d.h. wenn der Server-Thread irgendwo
    > einen parallel Stream starten will, kann das unter Last zu einem Dead-Lock
    > führen, da dann der Thread im ForkJoinPool auf einen freien Thread im
    > selben ForkJoinPool warten muss.
    >
    > Außerdem würde der Pool unter Last irgendwann keine weiteren Tasks mehr
    > annehmen weil er voll ist und submit würde eine Exception werfen. D.h.
    > durch die Idee etwas in einen Thread auszulagern hat man stattdessen nur
    > eine 500-Quelle unter Laste eingebaut.
    >
    > Und dann sind da noch die vielen kleinen Probleme, wie beispielsweise das
    > ein DeferredResult benutzt wird, obwohl eigentlich ein CallableFuture
    > benutzt werden sollte, der intern übrigens aus Threading-Sicht gruselig
    > programmiert ist, oder das der ForkJoinPool für die Aufgabe der völlig
    > falsche Executor ist.
    >
    > In der Summe: da hat ein Anfänger dran gesessen.

    Ja immer diese Anfänger von SAP und co. Du hättest das alleine sicher viel besser gemacht. Wir wissen Bescheid.

    Dein Fix für den synchronized Block hätte übrigens auch zu seltenen threading Problemen geführt, aber mach dir nichts draus du Profi. Kannst ja mal drüber nachdenken, eventuell kommst du nochmal drauf warum.

  12. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: burzum 02.06.20 - 09:57

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Tut er.

    Haha, klar. Was zu beweisen wäre...

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

  13. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: Gunslinger Gary 02.06.20 - 10:16

    Anstatt jetzt zu mosern, könntest du auch sagen ob er mit seinen Einschätzungen recht hat oder nicht. Seine Ausführungen finde ich ziemlich gut und leuchten mir ein.

    Nach deinem ersten Kommentar hatte ich Zustimmung oder eine gut argumentierte Antwort erwartet. Wissen habt ihr ja anscheinend beide genug.

    Verifizierter Top 500 Poster!

    Signatur von quineloe geklaut!

  14. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: twothe 02.06.20 - 16:43

    OtherOne schrieb:
    --------------------------------------------------------------------------------
    > Dein Fix für den synchronized Block hätte übrigens auch zu seltenen
    > threading Problemen geführt, aber mach dir nichts draus du Profi. Kannst ja
    > mal drüber nachdenken, eventuell kommst du nochmal drauf warum.

    Nein, da Zuweisungen von 64-Bit Werten in Java atomar ablaufen. Man kann zwar aus Threading-Sicht dann nicht sagen welcher Thread jetzt erfolgreich seinen Wert geschrieben hat, aber das ist im Programm so wie der Wert verwendet wird auch relativ egal, man will da ja eh nur irgend einen Zeitwert haben.

  15. Re: Rein geguckt, 3 schwere threading Bugs gemeldet

    Autor: OtherOne 04.06.20 - 00:43

    twothe schrieb:
    --------------------------------------------------------------------------------
    > OtherOne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dein Fix für den synchronized Block hätte übrigens auch zu seltenen
    > > threading Problemen geführt, aber mach dir nichts draus du Profi. Kannst
    > ja
    > > mal drüber nachdenken, eventuell kommst du nochmal drauf warum.
    >
    > Nein, da Zuweisungen von 64-Bit Werten in Java atomar ablaufen. Man kann
    > zwar aus Threading-Sicht dann nicht sagen welcher Thread jetzt erfolgreich
    > seinen Wert geschrieben hat, aber das ist im Programm so wie der Wert
    > verwendet wird auch relativ egal, man will da ja eh nur irgend einen
    > Zeitwert haben.

    Da bist du falsch informiert double und long sind nicht atomar. Hier geht es aber auch gar nicht darum. Eine rein atomare Zuweisung hilft dir in dem Fall nicht, daher war synchronized ok oder noch besser ein atomic. Und ja ich weiß, dass es in dem Fall eine Ref ist und kein primitiver Typ.

    Wie auch immer, mir geht es gar nicht um die fachlichen Details, sondern die Art und Weise.



    1 mal bearbeitet, zuletzt am 04.06.20 00:45 durch OtherOne.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Landkreis Potsdam-Mittelmark, Teltow
  2. FLYERALARM Digital GmbH, Würzburg
  3. ADAC e.V., München
  4. aluplast GmbH, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de