Steam Client Timeout auf Server

Ich habe die Tage im OZ.Tools plugin eine property hinzugefügt um den log4j logger zu deaktivieren, dann werden von allen plugins die logs ins hauptlog geschrieben. Das könnte den memory footprint minimal verkleinern. Ich habe die Version nur noch nicht getagged

Nein, das Wetter hat eigentlich keinen Einfluss auf den RAM (zumindest serverseitig)... du kannst aber den Native-Memory weiter aufbröseln indem du serverinfo nativememory in die Konsole eingibst - damit siehst du, welcher Bereich des Spiels wieviel nativen Speicher verbraucht. Der erste Wert ist hier ausschlaggebend (den "Total" Wert dahinter kannst du ignorieren). Mit BildAuf und BildAb kannst du dann in der Konsole hoch- und runterscrollen

Ah okay, dann geht es wohl um diese Methode hier

    /*
     * Check if an area (virtual area) intersects with an existing area and return the existing area or null
     */
    public static Area isAreaIntersecting(Area area) {
        for (Area a : Server.getAllAreas()) {
            if (a != null && a.intersects(area)) {
                return a;
            }
        }
        return null;
    }

Aber was daran genau problematisch ist kann nur red51 beantworten befürchte ich 😅

Der Crash wird möglicherweise durch den Aufruf Server.getAllAreas() durch das Plugin verursacht Schwer zu sagen, was hier tatsächlich das Problem ist... JNI ist leider sehr pingelig und gleichzeitig sehr schweigsam bei Fehlern oder Problemen.

Das hier ist die C#-seitige Implementation von Server.getAllAreas():

#region DELEGATE
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
private delegate JArray GetAllAreas_Delegate(IntPtr envPtr, JObject obj);
private static readonly GetAllAreas_Delegate _GetAllAreas = GetAllAreas;
[MonoPInvokeCallback(typeof(GetAllAreas_Delegate))]
[JavaNativeMethod(returnSignature: "[Lnet/risingworld/api/objects/Area;")]
#endregion
private static JArray GetAllAreas(IntPtr envPtr, JObject obj) {  //JArea[]
    try {
        JNIEnv env = JNIEnv.Get(envPtr);
        ArrayList<Area> areas = server.WorldManager.GetAllAreas();
        int length = areas.Count;
        JArray array = env.NewObjectArray(length, JArea.javaInfo.jClass, JArea.javaInfo.jConstructorID);
        for (int i = 0; i < length; i++) {
            Area area = areas[i];
            if (area != null && area.javaArea.IsValid()) {
                env.SetObjectArrayElement(array, i, area.javaArea);
            }
            else {
                env.SetObjectArrayElement(array, i, JArea.Zero);
            }
        }
        return array;
    }
    catch (Exception e) {
        PluginManager.ThrowJavaException(JNIEnv.Get(envPtr), JavaException.Exception, e.Message);
    }
    return default;
}

Sofern ich nichts übersehe könnte ich mir nur zwei Dinge vorstellen: Entweder die zur Area zugewiesene "javaArea" aus irgendeinem Grund nicht mehr valide ist. Die "javaArea" wird als globale Referenz gespeichert (damit sie nicht vom Java Garbage Collector erfasst wird).

Oder aber es steht der VM kein Speicher mehr zur Verfügung und das Erstellen des neuen Arrays schlägt fehl. Das Spiel prüft leider nicht, ob "env.NewObjectArray()" ein valides Array zurückgegeben hat (was nicht der Fall wäre, wenn zB kein Speicher mehr frei ist). Andererseits würde spätestens "env.SetObjectArrayElement()" darauf anschlagen, von daher weiß ich nicht, ob das überhaupt in Frage kommt... und innerhalb der Schleife gibt es auch keine neuen Allocations, daher sehe ich eigentlich keinen Bedarf für ein PopLocalFrame/PushLocalFrame o.ä

Devidian Unter welchen Umständen wird denn in deinem Plugin "isAreaIntersecting()" aufgerufen? Gibt es evtl. Situationen, in denen das sehr häufig aufgerufen wird (zB mehrmals hintereinander oder jeden Frame)?

SonoBionda Kann es sein, dass im Moment des Crashes oder kurz zuvor zB eine Area erstellt oder gelöscht wurde? Können andere Spieler generell ihre Area löschen bzw. haben sie Zugriff auf die Creative-Modus Area Werkzeuge (F9)?

Du könntest sonst evtl. nochmal folgendes zur server.properties Datei hinzufügen:

Plugins_JNIXcheck=True

und

Plugins_JNIVerbose=True

Damit könnte die Log-Datei dann ggf. ein paar mehr Informationen enthalten im Falle eines Crashes. Wenn es dann wieder crasht, poste bitte einmal die Log-Datei bzw. zumindest das Ende der Log-Datei (oder sende mir den Log via PN) und vll auch die hs_err_pid

Hmm also eigentlich war das hauptsächlich dafür gedacht beim erstellen zu prüfen ob eine existierende area, z.b. eine über F9 erstellte oder von einem anderen Plugin erstellte bereits den aktuellen chunk berührt oder im Fall das man einen claim erweitert wird der chunk geprüft in dem die area erweitert werden soll. Und wenn dem so ist sollte das erstellen oder erweitern unterbunden werden. Ja man kann Areas wieder löschen, die Methode verwendet aber dann diese Methode nicht, allerdings glaube ich das ich weiss worauf du hinaus willst, wenn jemand eine area löscht während getAllAreas ausgeführt wird dann könnte es eine null ref geben. Das aber so oft zur gleichen Zeit erstellt und gelöscht wird ist eher unwahrscheinlich, also wird ein Methode wohl wirklich zu oft diesen call machen.

Es gab aber auch noch andere Stellen wo ich das aufgerufen habe, ich werde mal sehen ob ich die calls dort reduzieren kann, ich glaube an mindestens einer Stelle kann ich es definitiv anders lösen.

Ich hab einige Stellen nun ausgetauscht und player.getCurrentArea(); verwendet wo es möglich war. Es sollte jetzt wirklich nur noch beim erstellen einer Area verwendet werden.

Bitte einmal die v0.6.1 ausprobieren SonoBionda

Quote from SonoBionda

Habe alles in die Wege geleitet -die beiden Einträge in die Properties und Landclaim 0.6.1

Dann schaun wir mal

mir fällt da noch was ein:

Ich hatte mit dem F9 Tool einige Server Areas erstellt und dabei nicht auf die Chunkborders geachtet. Das könnte vllt. den stellenweise Multirequest erklären. Ich werde die noch mal neu aufziehen und an den Chunkborders ausrichten.

Was ich auch noch ansprechen möchte ist die falsche Handhabung der Permissions nach dem claimen red51 - egal ob mit Tool oder über das Plugin - die werden nicht aktualisiert wenn man sich dann aus dem geclaimten Bereich entfernt - erst nach einem erneuten Einloggen

Display More

Ja das mit den Permissions der Areas stimmt. Wenn man eine Area löscht in der man sich gerade befindet, bleiben die aktuellen permissions bestehen. Auch wenn man respawned hat man noch die permissions aus der zone in der man gestorben ist, ist mir zumindest öfter mal aufgefallen.

Es ist gut zu hören, dass es jetzt scheinbar funktioniert! Demnach ist offensichtlich der Server.getAllAreas() Aufruf Schuld an den Crashes... ich habe mir das nochmal intensiv angeschaut, kann aber leider bisher nichts erkennen, was in dieser Methode Probleme bereiten könnte

Quote from Devidian

allerdings glaube ich das ich weiss worauf du hinaus willst, wenn jemand eine area löscht während getAllAreas ausgeführt wird dann könnte es eine null ref geben. Das aber so oft zur gleichen Zeit erstellt und gelöscht wird ist eher unwahrscheinlich, also wird ein Methode wohl wirklich zu oft diesen call machen.

Ja genau. Ob das jetzt aber hier wirklich der Fall ist bleibt schwer zu sagen... ein zu häufiger Aufruf sollte hingegen *eigentlich* kein Problem darstellen, außer es wird wirklich exorbitant häufig aufgerufen (jeden Frame mehrmals o.ä)

SonoBionda nur um das auszuschließen, Sachen wie zB das Nachladen von Plugins (mit dem reloadplugins oder rp Befehl) hast du aber während der crashenden Sessions nicht verwendet, oder?

Quote from SonoBionda

Ich hatte mit dem F9 Tool einige Server Areas erstellt und dabei nicht auf die Chunkborders geachtet. Das könnte vllt. den stellenweise Multirequest erklären. Ich werde die noch mal neu aufziehen und an den Chunkborders ausrichten.

Du meinst die Ausgabe "ChunkMultiRequest: Unable to create chunk!"? Dabei sollte es eigentlich keine große Rolle spielen, wie groß die Area ist. Die Ausgabe ist übrigens auch relativ harmlos (außer es wird dauerhaft gespammt). Im Grunde bedeutet das, dass ein Client Chunks angefordert hat, während der Server den angeforderten Chunk noch am generieren war. Das Spiel hat dafür einen Timeout drin und wenn es etwas zu lange dauert, dann kommt diese Ausgabe. Es hängt ein wenig von der Leistung des Servers ab (CPU, aber auch Festplattengeschwindigkeit usw).

In dem Fall wird der Chunk aber einfach erneut vom Client angefordert. D.h. es dauert lediglich etwas länger für den Client (vmtl. einige Sekunden), bis er seine Chunks bekommt, aber es geht dabei nichts kaputt. Sofern diese Meldung also nicht gespammt wird kann man sie weitgehend ignorieren

Quote from SonoBionda

Was ich auch noch ansprechen möchte ist die falsche Handhabung der Permissions nach dem claimen red51 - egal ob mit Tool oder über das Plugin - die werden nicht aktualisiert wenn man sich dann aus dem geclaimten Bereich entfernt - erst nach einem erneuten Einloggen

Du meinst wenn man sich als Spieler aus der Area löscht (oder die Area löscht)? Oder wenn man einfach aus der Area herausgeht? Ich meine ich hätte Ersteres behoben (der Fix wäre dann mit dem nächsten Update verfügbar), aber ich schaue mir das auf jeden Fall nochmal genauer an

--------------------------------

Noch zu deiner vorherigen Frage wegen dem Speicher bzw. was "Cpp" bei der Ausgabe "serverinfo nativememory" bedeutet: Das ist der Speicher, der von C++ allocated wurde. Derzeit findet die Chunkgenerierung (also das Erstellen der eigentlichen Meshes) in C++ statt, dort kommt der Verbrauch her. Ein Verbrauch von 300 MB ist aber absolut im grünen Bereich. Alle obigen Werte die du gepostet hast sind völlig in Ordnung.

Die Ausgabe unter "serverinfo nativememory" ist im Grunde nur interessant, wenn zB der native Memoryverbrauch plötzlich sprunghaft steigt (wie du ja ursprünglich beim Wetter vermutet hattest). Da kann der Befehl dann helfen herauszufinden, wo das hinfließt

Quote from SonoBionda

Das meinte ich - wenn man eine Area mit F9 erstellt und sich innerhalb dieses Bereichs befindet, muss man erst raus gehen und wieder rein damit die Berechtigungen aktualisiert werden.

Hmm... sorry dass ich da nochmal nachhake, aber ich bin mir noch nicht ganz sicher, wie du das meinst. Das normale Verlassen einer Area sollte die Permission eigentlich wieder zurücksetzen (auf die eigentliche Standardpermission des Spielers)... oder meinst du dass wenn die Berechtigung einer Area geändert wird während ein Spieler in dieser Area ist, dass er dafür erst raus und wieder rein muss, damit diese Änderungen für ihn aktiv werden?

Quote from SonoBionda

Vielleicht hab ich das ein-/zweimal benutzt. Aber ich denke, das kann man trotzdem ausschließen, da er ja tagelang in einer Tour gecrasht ist. Seit der Änderung im Plugin läuft er immer noch einwandfrei

Achso, also ich wollte nur sicherstellen, ob der Server auch crashte, wenn in der Session dieser Befehl nicht verwendet wurde. Das Nachladen von Plugins kann theoretisch für Crashes sorgen, aber nur innerhalb derselben Session (d.h. wenn es irgendwann nach einem Restart crasht, dann hängt das nicht miteinander zusammen). Freut mich aber, dass der Server soweit läuft (wobei ich schon gerne auch die eigentliche Crash-Ursache abstellen würde)

Also das was SonoBionda meint, fällt mir immer nur wieder auf, wenn ich in einer Area stehe und diese lösche, sagen wir mal "Devidian's Home" dann laufe ich in die Area "SonoBionda's Home" und bin in ihrer Area mit den dortigen Rechten, wenn ich aber wieder raus laufe bin ich nicht in "Wildnis" sondern wieder in "Devidian's Home". Wildnis gibt es quasi nicht mehr für mich, bis ich neu einlogge. Vielleicht muss ich mal ein YT Video dazu machen.