Subprozess auf Application Server ausführen

[polofan123]

Hi,

Ich habe folgendes Problem : Ich versuche externe Programme (Skripte, jars usw.) von meinem Application server (glassfish 3.1.2) aus aufzurufen. Das mache ich mithilfe der "apache commons exec" Bibliothek.

1) Wie bekomme ich es am besten hin zu verhindern, dass zu viele dieser Prozesse aufgerufen werden und mein Server damit überlastet wird.
Da der application server von den extern aufgerufenen Prozessen überhaupt nichts weiß, kann er auch nicht wissen wann sie beendet und das Ergebnis zur Verfügung steht oder ob sie gar blockieren und abgebrochen werden müssen.
Ich dachte deshalb daran EJBs zu verwenden um die Prozesse aufzurufen. Ein EJB würde dann einen Prozess aufrufen und danach auf das Ergebnis warten. In der Zeit würde es einfach sinnlos existieren. Zusätzlich beschränke ich die Anzahl der EJB Instanzen auf z.B 10 und infolge dessen können auch nie mehr als 10 Prozesse gestartet werden. Gibt es vielleicht eine sinnvollere Lösung?

2) Um zu erkennen ob ein extern gestarteter Prozess blockiert bietet apache commons exec einen watchdog an, der einen Prozess nach blockieren von X Sekunden beendet. Dieser watchdog ist aber ein Thread und Threads sollten ja im application Server nicht gestartet werden, da dieser sie nicht verwalten kann bzw. nicht einmal von deren Existenz weiß. Gibt es eine Möglichkeit dem Application Server die Existenz eines solchen Threads mitzuteilen?


ich wäre für jede Art von Hilfe oder Diskussionsbeiträgen dankbar 😉

 

[FArt]

Ich würde sagen, Prozesse aus einem EJB zu forken ist gegen die Spec ;-)

Du könntest es evtl. über ein Singleton EJB mit eigene Synchronisation regeln und dort dann deine Logik bgzl. der Begrenzung der Prozesse / Queueing realisieren.

 

[freez]

Wie wäre es denn einen eigenen Handler für deine Prozesse zu schreiben, in denen du dann einschränken oder frei geben kannst wie du willst. Starten und Beenden könntest du ihn dann z.B. über einen ServletContextListener.

Solltest du Spring einsetzen, so bietet der Spring Scheduler auch interessante Möglichkeiten.

 

[FArt]

Wie wäre es denn einen eigenen Handler für deine Prozesse zu schreiben, in denen du dann einschränken oder frei geben kannst wie du willst. Starten und Beenden könntest du ihn dann z.B. über einen ServletContextListener.

Solltest du Spring einsetzen, so bietet der Spring Scheduler auch interessante Möglichkeiten.

Könntest du genauer ausführen, wie dieser Handler realisert werden soll, so dass er aus EJBs heraus genutzt werden kann?
Wieso ServletContextListener? Die Frage dreht sich (bisher) um EJBs und Applicationserver.

 

[freez]

Nun, der TO möchte ja EJB's missbrauchen um externe Prozesse zu starten (die ja wegen "externe Prozesse" wenig mit den EJBs auf dem AppServer selbst zu tun haben)

In einem AppServer kann man doch einen ServletContextListener registrieren, bei dem bei AppStart und Ende entsprechende Methoden aufgerufen werden URL.

Hier könnte der TO einen eigenen Handler entwickeln, der die externen Prozesse aufruft und diese natürlich auch vollständig kontrollieren kann (WatchDog, Anzahl Threads usw.). Gestartet würde der Handler in der [c]contextInitialized()[/c] Methode und beendet [c]contextDestroyed()[/c] Methode.

Ich setze hierbei vorraus, das der TO seine Prozesse (Jars / Scripts etc.) per Runtime.exec() startet. Sollten die Prozesse im Context der App laufen, dann müsste man prüfen, ob das überhaupt geht.

 

[freez]

Vielleicht noch ein Hinweis: Man kann für solche Sachen natürlich auch die Bestriebssystemspezifischen Tools verwenden (Scheduled Task => Win / Cron => Linux).

Allerdings stand auch ich vor dem Problem, dass die Anwendung einfach zu installieren sein sollte und diese Asynchronen Tasks (E-Mail versenden, DB aufräumen) waren mit der Anwendung eng verknüpft, sodass ich mich damals für den Spring Scheduler entschieden habe und diese Tasks auf dem Tomcat habe laufen lassen.

Bei externen Prozessen, die über Runtime.exec gestartet werden, müsste man prüfen, ob man die auch killen kann, ohne den App Server mit zu killen. Dann sollte es auch kein Problem machen, wenn man mal so ein Script abschiessen muss. Aber ich würde an der Stelle wohl cron, oder die Scheduled Tasks bevorzugen.

 

[polofan123]

Also am liebsten wäre es mir ja gewesen dazu direkt den Threadpool des Glassfish Server zu gebrauchen. Dann würde der Server das Management meiner Threads übernehmen. Hinweis : Die Prozesse müssen nicht zwingend aus einem EJB heraus gestartet werden und deine Möglichkeit einen eigenen Handler zu schreiben ist natürlich immer da aber ich könnte mir die ganze Arbeit dafür sparen wenn ich Zugang zum Application Server Threadpool hätte :/