Questions & Answers

[Anonymous]

Wir benutzen in einem Projekt die FirstSpirit Version 5.2R11 und das RsyncDeployment Modul (Version 1.1.1). Von Zeit zu Zeit liefert das RsyncDeployment Modul eine ClassCastException. Nach einem Neustart des FirstSpirit-Servers ist die ClassCastException verschwunden.

ERROR 16.08.2017 12:26:35.707 (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): error in task 'rsync-Deployment' - schedule entry 'Veröffentlichung' (id=3021) - java.lang.ClassCastException: com.espirit.ps.custom.rsyncdeploy.RsyncDeployData cannot be cast to com.espirit.ps.custom.rsyncdeploy.RsyncDeployData
java.lang.ClassCastException: com.espirit.ps.custom.rsyncdeploy.RsyncDeployData cannot be cast to com.espirit.ps.custom.rsyncdeploy.RsyncDeployData
    at com.espirit.ps.custom.rsyncdeploy.RsyncDeployExecutor.execute(RsyncDeployExecutor.java:37)
    at de.espirit.firstspirit.scheduling.ConfigurableScheduleTask.execute(ConfigurableScheduleTask.java:31)
    at de.espirit.firstspirit.scheduling.ConfigurableScheduleTaskExecutor.run(ConfigurableScheduleTaskExecutor.java:15)
    at de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl$TaskCallable.executeLocal(ScheduleManagerImpl.java:2409)
    at de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl$TaskCallable.executeLocal(ScheduleManagerImpl.java:2392)
    at de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl$TaskCallable.call(ScheduleManagerImpl.java:2312)
    at de.espirit.firstspirit.server.ExecutionManagerImpl$ExtendedCallable.call(ExecutionManagerImpl.java:590)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at de.espirit.common.util.BoundedExecutorService$RunnableWrapper.run(BoundedExecutorService.java:436)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at de.espirit.common.util.SuspendableThread.run(SuspendableThread.java:56)

[marza]

Hallo Klaus,

Könnte es sein, dass in der Zwischenzeit ein anderes Modul aktualisiert oder installiert wurde? Wenn Services im Spiel sind und somit der Server-Class-Path mit neuen Jars erweitert wurde, sollte man immer den FirstSpirit-Server neustarten, damit der Server-Class-Path überall reinitialisiert wird.

Grüße

Marian

[Anonymous]

Es wurde in der Zwischenzeit kein anderes Modul aktualisiert oder installiert. Einen Neustart des FirstSpirit-Servers nach der Installation bzw. Update eines Moduls mache ich immer .

[Anonymous]

rrichter​ wollte ein Ticket einstellen. Er hatte die Problematik auch schon mal.

[brueder]

Hallo Claus,

ich gehe dann davon aus, dass dir im Rahmen des Tickets geholfen wird, und schließe das Thema. Wenn du dennoch hier weitere Hilfe benötigst, öffne das Thema hier bitte erneut, oder lege ein neues an.

Viele Grüße,

Lena

[rrichter]

Hallo Klaus,

ist das Problem eigentlich reproduzierbar?

Wir haben hier im Rahmen unseres Tickets noch einmal nachgeforscht, konnten aber auch nur den Zusammenhang bestätigen, den Marian schon genannt hat. Bei uns tritt das nur in Zusammenhang mit aktualisierten Modulen ohne Serverneustart auf.

Viele Grüße,.

Raphael.

[Anonymous]

Hallo Raphael,

leider lässt sich das Problem nicht reproduzieren. Es ist von Zeit zu Zeit aufgetaucht. Der beschriebene Fall in Zusammenhang mit einer Aktualisierung der FirstSpirit Module ohne Neustart des FirstSpirit Servers kann ich bestätigen.

Grüße,

Klaus

[dominik_koenig]

Hallo Raphael,

ich hatte das selbe Problem vor einiger Zeit. Die Exception ist immer erst nach einiger zeit aufgetreten. Um so mehr Traffic auf dem Server war, umso früher ist der Fehler aufgetreten (Wir haben ca. alle 3 Minuten ein Deployment, wobei jedes mal der Rsync 2 mal ausgeführt wird, manchmal sogar häufiger).

Hatte das Problem auch noch mit anderen Modulen aber nicht so häufig wie bei diesem.

Mein Workaround war ein relativ langes Script direkt in der Auftragsverwaltung zu benutzen, statt dem Modul.

Ich glaube eher das ist ein Allgemeiner Fehler mit FirstSpirit.

Grüße,

Dominik

[sbrandt68]

Hallo, wir haben hier bei uns des öfteren das Gleiche Problem.

Bei uns tritt dies nur auf nachdem wir ein anderes, eigenes Modul installiert haben.

Nur durch ein neustart des Servers kann dies dann behoben werden.

Grundsätzlich ist es natürlich nicht wünschenswert, nur da wir ein kleines Hilfsmodul upgedatet haben, den FS Server neu zu starten.

Dies ist am Tag natürlich auch nicht so schön, da ja diverse Redakteure mit dem Systen arbeiten. Andererseits gehen die Deployments dann für alle Projekte nicht mehr.

Ein Trick der funktioniert ist:

* Man öffnet die Auftragsplanung in einem Projekt

* geht zu der entsprechenden Deployment Aktion

* und speichert diese einmal neu ab

Dann ging der Job bei uns wieder durch, warscheinlich lädt er dann die richtigen Klassen irgenwie nach.

Leider muss man dies aber für jeden einzelnen Deployment Auftrag Aktion machen, funktioniert nicht Projektübergreifen, ist also auch nicht richtig zu gebrauchen

[hbarthel]

Hallo zusammen,

dasselbe beobachten wir ebenfalls mit Version 1.1.1 und FS 5.2R15. Nach einiger Zeit tritt dieses Problem auf, ohne, dass vorher eine Modulinstallation stattfand. Keine Ahnung, was das verursachen könnte. Wir haben kürzlich von der Skriptvariante zum Modul gewechselt und überlegen, ob wir nicht wieder zurück gehen sollten.

Gruß, Heiko