Kursaktualisierung: "Aktuelle Kurse" werden nicht immer direkt verarbeitet

Version: 0.76.3 (Mai 2025)
Platform: win32, x86_64
Java: 21.0.5+11-LTS, Azul Systems, Inc.

Ich bin vor ein paar Tagen von 0.75.1 auf 0.76.3 umgestiegen und habe nun ein Problem mit der Kursaktualisierung.

Die aktuellen Kurse werden zwar korrekt vom Server (Kurslieferant: JSON) abgerufen und empfangen. In der Benutzeroberfläche werden die aktualisierten Kurse aber nur bei manchen Werten angezeigt, und es werden auch nur diese in die Berechnungen (TTWROR, Widget “Gesamtsumme (Gesamtportfolio)”, …) einbezogen:

(Diese drei Wertpapiere nutzen denselben Kurslieferanten; der besseren Übersicht wegen habe ich die anderen ausgeblendet.)

Aktualisiere ich die Kurse kurz darauf erneut, werden keine neuen Anfragen an den Server gesendet. Dafür werden in der Benutzeroberfläche nun auch die bislang nicht aktualisierten Kurse aktualisiert:

Für mich deutet das darauf hin, dass sich die Daten aus dem ersten Kursabruf noch im Cache befinden, also erfolgreich empfangen wurden, aber eben nicht verarbeitet.

Da ich die Kurse von meinem eigenen Server abrufe, kann ich die Abrufe und zurückgegebenen JSON-Daten gut nachvollziehen. Beim ersten Abruf wurden alle drei Wertpapiere abgefragt. Für jedes Wertpapier wurde mit den Kursen geantwortet, die in der zweiten Abbildung angezeigt werden.

Der Abruf erfolgt mittels “Kurse aktualisieren (nur aktive Wertpapiere)” und die entsprechenden Wertpapiere sind allesamt aktiv. Im Fehlerprotokoll gibt es keine Hinweise auf Fehler.

Ich kann das Verhalten zuverlässig reproduzieren, allerdings sind nicht immer dieselben Wertpapiere betroffen. Ein Muster konnte ich keines erkennen. Während der ersten Aktualisierung meine ich in der Vermögensaufstellung zu erkennen, dass alle Kurse kurz aktualisiert werden, bevor manche dann auf den Ausgangszustand zurückspringen. Das geht aber so schnell, da will ich mich nicht festlegen.

1 Like

Danke für die Meldung. Ich werde versuchen das bei mir zu reproduzieren. Ich weiß ich habe Änderungen am Kursabruf gemacht, aber nicht an dem JSON Kurslieferant.

@melita Kannst Du mir mal Deine Datei - ohne Buchungsdaten, aber mit der Konfiguration der Wertpapiere - zukommen lassen? Am besten per email an portfolio dot performance dot help at gmail dot com.

Ich habe das versucht das Problem mit einem (lokalen) JSON Kurslieferanten nachzustellen, aber mir ist nicht klar was das schief geht.

Was passiert eigentlich, wenn Du die Ansicht noch mal neu öffnest - also z.B. in der Seitennavigation noch mal auswählst - ohne noch mal die Kursaktualisierung anzustoßen?

Das kann ich nachvollziehen. Diese golang-script liefert die aktuelle Unixtime als Kurs.

package main

import (
	"net/http"
	"fmt"
	"strconv"
	"time"
)

func unixtime_as_quote(w http.ResponseWriter, req *http.Request) {
	t := strconv.FormatInt(time.Now().Unix(), 10)
	fmt.Println(t)
	jsonstr1 := "{\"name\":\"Test - Timestamp as quote\",\"price\":"
	jsonstr2 := ",\"date\":"
	jsonstr3 := "}"
 	jsonstr0 := jsonstr1 + t + jsonstr2 + t + jsonstr3
	fmt.Fprintf(w, jsonstr0)
}


func headers(w http.ResponseWriter, req *http.Request) {
	for name, headers := range req.Header {
		for _, h := range headers {
			fmt.Fprintf(w, "%v: %v\n", name, h)
		}
	}
}

func main() {
	http.HandleFunc("/", unixtime_as_quote)
	http.HandleFunc("/headers", headers)
	http.ListenAndServe(":8083", nil)
}

Mit einigen Wertpapieren, die alle diesen Server als Quelle für aktuelle Kurse nutzen, sieht man


und als Ausgabe des Servers

me@host:~/TEST/go$ go run unixtime_as_quote.go 
1749460994
1749460994
1749460994
1749460994
1749460994
1749460994
1749460994
1749460994
1749460994
1749460994

Interessant ist: Beim Start von PP mit dieser xml, kommen nur 10 Requests beim Server an, es werden aber bei allen 12 Wertpapieren der gleiche Kurs angezeigt.

Mit “Kurse aktualisieren (nur aktive Wertpapiere)” passiert nichts, auch nicht beim Server, es kommen keine Requests.

Zum Spielen:
time_as_quote.xml (17,9 KB)

Vergiss das. Wenn man die URL von http://localhost:8083 auf http://localhost:8083/{ISIN} ändert, werden 12 Requests geschickt.

Das bleibt so (wenn die Zeit zwischen 2 Aktualisierungen klein ist). Ist der Zeitabstand etwas größer kommen die Requests.

Um ISINs ergänzte Spieldatei:
time_as_quote.xml (18,6 KB)

auf fmt.Println(t, req.URL.Path) ändern, um auch dort die ISINs zu sehen.

Das liegt an etwas anderem: es werden bis zu 10 Requests parallel gemacht. Am Anfang ist der Cache immer leer, d.h. es werden tatsächlich 10 gleiche Requests losgeschickt. Für den 11. und 12. Anfrage sind dann Daten im Cache. Die werden dann verwendet.

Das Problem von @melita ist - wenn ich das richtig verstanden habe - ein anderes. Die Requests kommen beim Server an und werden auch gecacht (da ja bei einer weiteren Abruf keine Requests geschickt werden), aber das UI aktualisiert sich nicht.

Das kann “normale” Gründe haben: Das UI wird nicht nach jeder Anfrage aktualisiert - ansonsten wäre es sehr schnell überfordert mit der ständigen Neuberechnung der Werte - sondern nur alle 20 aktualisierte Wertpapiere oder wenn der Job beendet ist. Wenn es jetzt einen Langläufer gibt weil eine Server hängt, kann das natürlich das Update des UIs verzögern.

Es könnte auch noch ein Bug sein. Ich kann das Problem aber bisher nicht nachstellen.

Moin!
Zur Info: Ich hab das Phänomen auch schon beobachtet:
In der Wertpapierübersicht werden nicht alle aktuellen Kurse direkt korrekt angezeigt, so heute auch wieder (siehe Abbildung). Die Daten sind nach der Spalte “Letzter (Datum)” sortiert. Ich hab dann testweise einfach mal diverse andere Ansichten angewählt und wieder zurück, aber keine Aktualisierung in der Wertpapier-Ansicht.
Erst nachdem ich erneut “Kurse aktualisieren” angewählt habe, wurden auch die anderen Kurse korrekt mit dem letzten Datum von 6.6.2025 angezeigt. Alle Kurse haben als Lieferanten “portfolio report”, ausser EUWAX Gold.

Gruß
Stefan

PS Eigentlich kein Problem, wenn man weiss das man die Kurse noch nochmal aktualisieren muss. Aber vielleicht hilft es bei der Fehlerfindung …
Mein System:
Version: 0.76.3 (Mai 2025)
Platform: linux, x86_64
Java: 21.0.7+6-Ubuntu-0ubuntu122.04, Ubuntu

Ich habe das eben auf die Schnelle versucht: Buchungen entfernt und drei Wertpapiere per Einlieferung hinzugefügt. Allerdings lässt sich das Problem dann nicht mehr reproduzieren. Vielleicht benötigt man eine bestimmte Anzahl zu aktualisierender Wertpapiere, oder solche mit unterschiedlichen Kurslieferanten. Ich werde es im Laufe der Woche nochmal probieren, wenn ich mehr Zeit habe.

Mit meiner Hauptdatei konnte ich das Problem am gestrigen Sonntag übrigens erstmals nicht mehr reproduzieren. Daraufhin habe ich die Kurse aktualisiert und die Datei gespeichert. Mit dieser Datei habe ich das Problem auch heute nicht mehr. Mit einem Backup der Datei vom Donnerstag, als ich dieses Thema erstellt habe, tritt es aber weiterhin auf.

An den angezeigten Werten ändert sich dadurch nichts; sie bleiben so, wie in der ersten Abbildung.

Probeweise habe ich nach dem ersten Kursabruf das Portfolio mit den unvollständigen Kursdaten unter neuem Dateinamen gespeichert, PP neu gestartet, und die neue Datei geöffnet. Aber auch hier waren die Kursdaten weiterhin unvollständig.

Im Performance-Dashboard habe ich ein Gesamtsumme-Widget, dessen Wert ebenfalls auf Basis der angezeigten unvollständigen Kursdaten berechnet wird. Dieser Wert stimmt stets mit der Summe in der Vermögensaufstellung überein. Ein zweiter Kursabruf korrigiert auch den Wert im Gesamtsumme-Widget. Es scheint sich also um kein reines Darstellungsproblem zu handeln.

Nur zur Bestätigung: das ist korrekt.

Ich glaube ich habe eine Idee. Könntest Du noch mal teilen wie genau die historischen und wie genau die letzten Kurse konfiguriert sind? Sind das unterschiedliche Lieferanten?

Ja - die historischen Kurse der betroffenen Wertpapiere kommen größtenteils von Portfolio Report (in einem Fall Yahoo Finance):

“Aktueller Kurs” der betroffenen Wertpapiere ist ausnahmslos so konfiguriert:

Die Server-Antwort sieht z.B. so aus:

HTTP/1.1 200 OK
Date: Sat, 14 Jun 2025 09:06:27 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Server: nginx
Cache-Control: no-store
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

{"via":"source","date":"2025-06-13T20:58:37.765+00:00","current":128.16}

Gestern konnte ich das Problem noch reproduzieren, heute wieder nicht.

@AndreasB

Mit der angehängten Datei kann ich das Problem nun stabil reproduzieren:
pp-kurs-debug.xml (16,0 KB)

Als JSON-Datenquelle habe ich eine URL angegeben, die statisch folgende Antwort liefert:

{"record":{"via":"debugstatic","date":"2025-06-14T22:22:49.000+02:00","current":222.22},"metadata":{"id":"684de8a48561e97a50245cfc","private":false,"createdAt":"2025-06-14T21:24:52.272Z","name":"ppdebug"}}

Hier der Ausgangszustand der Portfolio-Datei (bei mir ist die Option “Wertpapierkurse nach dem Öffnen der Datei automatisch aktualisieren” nicht aktiv):

Nach erstem “Kurse aktualisieren (nur aktive Wertpapiere)”:

Nach zweitem “Kurse aktualisieren (nur aktive Wertpapiere)”:

[…]

Nach ca. sechstem “Kurse aktualisieren (nur aktive Wertpapiere)”:


Ich vermute einen Zusammenhang mit der Aktualität der historischen Kursdaten. In meiner Datei stammen die letzten historischen Kurse vom Donnerstag; jene von Freitag fehlen also und werden erst beim Aktualisieren eingefügt. Dabei scheint es zu einem abwechselnden, gegenseitigen Überschreiben mit dem “Letzten Kurs” zu kommen.

Zum Vergleich eine Kopie der Datei, aber bereits mit Freitagskursen:
pp-kurs-debug-2.xml (16,4 KB)
Hier tritt das Problem überhaupt nicht auf; der “Letzte Kurs” wird stets sofort auf 222,22 gesetzt und bleibt auch dort.

2 Likes

Vielen Dank @melita für das ausführlich Beispiel. Ich glaube ich habe das Problem gefunden: der Portfolio Report feed hat - entgegen der Konfiguration - ebenfalls den letzten Kurs gesetzt und gegebenenfalls überschrieben.

Diese race condition was schon länger im Code. Jetzt habe ich aber die Art und Weise geändert wie die Jobs auf “rate limited exceeded” reagieren. Dadurch hat sich auch leicht geändert in welcher Reihenfolge die ausgeführt werden. Ich vermute dadurch erhöht sich die Wahrscheinlichkeit, dass Du das Problem siehst.

Der Fix kommt mit der nächsten Version - dann schauen wir mal.

3 Likes

Nur zur Bestätigung: Mit der neuen Version 0.77.2 tritt das Problem bei mir nun nicht mehr auf. Vielen Dank @AndreasB

1 Like