Frage zur Begrenzung auf eine laufende Instanz
-
Ist es zwingend erforderlich, MediathekView auf eine Instanz zu begrenzen oder ist das eher eine Maßnahme für den Standarduser?
Hintergrund: Bisher hatte ich MediathekView 13.0.6 als Arbeitsumgebung und nebenbei neuere Develop-Versionen in IntelliJ getestet, natürlich mit einem eigenen Konfigurations-Verzeichnis.
Seit dem Umstieg auf 13.7.0 kann ich MediathekView innerhalb der Develop-Umgebung nicht mehr starten, es erscheint dann sofort die (korrekte) Meldung, dass MV schon läuft. Die Semaphore MediathekView.lock liegt im Temp-Verzeichnis und könnte manuell leicht gelöscht werden.Frage an die Experten: Gibt es bekannte Überschneidungen von Funktionen bei mehreren laufenden Instanzen? Oder betrifft das lediglich den Zugriff auf das Konfigurations-Verzeichnis? Wenn letzteres, wäre es dann nicht sinnvoll, den Lock in diesem Verzeichnis abzulegen statt in einem globalen Verzeichnis?
-
@menchensued Exzellente Frage, die mich auch brennend interessiert - ich will ja nicht mit mehreren virtuellen Maschinen herumspielen - von den JVMs mal abgesehen …)
-
Es ist ZWINGEND erforderlich, nur eine Instanz von MediathekView am laufen zu haben!
Grund ist die Art wie Xaver bei Beginn der Programmentwicklung den Zugriff auf die ganzen Config-Files designed hat. Diese werden/können bei Zugriff nicht gelocked werden und somit ist die Gefahr enorm dass dann mehere MV Prozesse auf die gleiche Datei zugreifen und Schrott produzieren, was den erneuten Start verhindert da alles im Eimer ist.
Ich bin Stück für Stück ja dabei das umzuschreiben aber das ist nicht ganz so einfach wie gedacht und die Migration muss auch durchdacht sein. -
Im Grunde bräuchte man den Start einer weiteren Instanz nur dann abbrechen oder verweigern, wenn die neue Instanz ein Einstellungsverzeichnis nutzen will, das bereits von einer laufenden Instanz benutzt wird. Ist aber mehr Aufwand.
Die aktuelle Verfahrensweise lässt allerdings trotzdem ein Schlupfloch, denn die funktioniert nur für die Instanzen eines Windowsbenutzers.
-
@mvsfsvm sagte in Frage zur Begrenzung auf eine laufende Instanz:
Im Grunde bräuchte man den Start einer weiteren Instanz nur dann abbrechen oder verweigern, wenn die neue Instanz ein Einstellungsverzeichnis nutzen will, das bereits von einer laufenden Instanz benutzt wird. Ist aber mehr Aufwand.
Richtig. Aber mal ganz ehrlich: Wer in der Lage ist den Code zu lesen sollte auch in der Lage sein in der Klasse Main in der function
public static void main(final String... args)den call
installSingleInstanceHandler();durch//installSingleInstanceHandler();
zu ersetzen und neu zu starten.Die aktuelle Verfahrensweise lässt allerdings trotzdem ein Schlupfloch, denn die funktioniert nur für die Instanzen eines Windowsbenutzers.
Falsch:
Hier für Linux:
und macOS:
Die macOS verwendet sogar zwei Verfahren um den Doppelstart zu verhindern, nämlich das interne als auch das durch das Betriebssystem bereitgestellte…
-
@mvsfsvm Oder meinst Du mehrere gleichzeitig angemeldete Nutzer am Rechner?
Open source developers do NOT have to:
- Make your issue a priority, just because you say so.
- Give you any sort of "timetable", or explanation for why it´s "taking too long".
Check your entitlement. Nobody owes you anything.
-
@derreisende77 ja ich meinte mehrere gleichzeitig angemeldete Benutzer. Wobei ich unter Windows bisher für die zusätzliche Instanz Unter anderem Nutzer starten verwendete. Findet man im Kontextmenü wenn man es per Umschalt+Rechtsklick öffnet. Das scheint aber tatsächlich nicht mehr zu funktionieren. Es gibt allerdings auch keine Fehlermeldung.
-
@derreisende77
Ich wollte hier keine Grundsatzdiskussion vom Zaun brechen, mir ging es speziell um zwei Usergruppen:- Entwickler, die neben der freigegebenen Version parallel an einer Entwicklerversion etwas ausprobieren wollen
- Spezialanwendern, die mehrere Konfigurationen haben (da gab es mal jemanden, der wollte den Download immer in zwei unterschiedlichen Auflösungen haben)
Beiden ist gemein, dass ein getrenntes Konfigurationsverzeichnis .mediathek3 verwendet wird. Aber so wie ich Dich verstanden habe, besteht durchaus die Gefahr, dass der Code noch auf das falsche Verzeichnis zugreifen könnte, obwohl man per Parameter ein anderes Verzeichnis haben wollte. Das war zumindest früher bei Logfiles so.
Sicher ist es besser, die jetzige Begrenzung zu respektieren, da man ansonsten nie sicher sein kann, dass es Nebeneffekte geben könnte. -
@menchensued Naja, ein wenig Diskussion braucht man ja schon, von daher alles gut ;)
Den use case für ein Locking auf das jeweilige Config-Verzeichnis hatte ich nicht auf dem Schirm da ich es schlicht nicht nutze und es da auch keine explizite Anforderung zu gab. Aber ich habe gerade ein wenig darüber nachgedacht und denke das dies “nicht so schwer” umzusetzen ist.
Könntest Du dafür ein github issue zu aufmachen, dann gerät es nicht in Vergessenheit.Mein grundsätzliches Problem ist dass viele Nutzer versuchen MV manuell mit irgendwelchen Parametern zu starten die ggf. auf noch veraltet sind. Dadurch kann es zu negativen Seiteneffekten kommen. Von daher reagiere ich da immer etwas allergisch wenn man den Startvorgang verändern will. Ich persönlich kann das nicht nachvollziehen und das war auch der Hauptgrund den Installer anzubieten.
Das Problem mit den Logfiles sollte behoben sein.
Die Usergruppe Entwickler betrachte ich persönlich nicht, denn die sollten in der Lage sein den Quellcode an ihre Ansprüche zu modifizieren. Und sie fragen auch in der Regel im Forum nicht um Hilfe wenn sie etwas verbeutelt haben ;)
Für den zweiten Fall überlege ich mir was wenn der issue da ist. Das kommt aber nicht mehr in 13.7.1. Die ist quasi final und geht demnächst auf die Reise.
-
@menchensued Das grundsätzliche Problem mit mehreren Instanzen ist das diese auch derzeit jeweils eigene Filmlisten laden und damit den Traffic erhöhen. Das abzufedern würde eine deutlich komplexere MV Installation leider bedeuten :(
Open source developers do NOT have to:
- Make your issue a priority, just because you say so.
- Give you any sort of "timetable", or explanation for why it´s "taking too long".
Check your entitlement. Nobody owes you anything.
-
@derreisende77
Danke für die Erklärungen. Vermutlich ist es wirklich besser, nicht zu viele Sonderfälle zu implementieren, denn dadurch erschwert sich auch die Fehlersuche. Daher verzichte ich erst mal auf ein Ticket. -
@menchensued in der Regel geht es doch darum, eine neue Version erst einmal mit eigener Konfig zu testen oder eine 2. Instanz mit anderer Konfig zu verwenden, weil das Vorhaben nicht mit einer einzelnen Instanz machbar ist (siehe dein Beispiel mit den Spezialanwendern). Das wäre alles mit einem Locking auf das Config-Verzeichnis abgedeckt.
