Aus gegebenem Anlass wurden mal wieder ein paar Features von EJB/JEE Standard und Spring gegenüber gestellt, das hat mich an eine Frage erinnert die ich schon lange mal stellen wollte: Gibt es bei Spring ein Gegenstück zum EJB Pooling? Das Pooling ermöglicht mir ja, gewisse Caches an Instanzen vorzubehalten, um auf den zu erwartenden Traffic zu reagieren. Ich beschäftige mich gerade intensiv mit dieser Materie, da ich Architekturvorschläge für eine ‘High concurrency’ Anwendung vorlegen soll.
Als Beispiel könnte ich z.B. eine MessageDriven Bean erstellen, welche auf Eingaben aus einer JMS Queue reagiert und die Anfragen asynchron abarbeitet. Für eine kleinere Anwendung würde ich eine Bean vorhalten, wenn aber jetzt eine riesige Nachfrage kommt, könnte ich den Bean Pool erhöhen und 20 Beans dieser Instanz erstellen lassen, welche die Queue parallel abarbeiten. Das kann ich alles dynamisch zur Laufzeit anpassen, was es mir ermöglicht das Verhalten der Anwendung zur Laufzeit zu optimieren. Für die meisten meiner ‘Brot und Butter Features’ aus dem JEE Standard kenne ich Gegenstücke in Spring, hierzu konnte ich bisher nichts finden.
Ich meine das gibt es nicht out-of-the-box, schliesslich vermarktet sich Spring als „leightweight“ (ob das stimmt steht auf einem anderen Blatt), Instanzen in Java zu erzeugen ist ja nicht „teuer“ von Haus aus, was es teuer machen kann sind Overheads undJEE Server haben da einige, schliesslich ist dort alles „Containermanaged“.
Wenn man framworks/technologien wechselt sucht man oft nach Gegenstuecken, auch wenn man sie gar nicht braucht, viele JEE Features sind entweder noetig weil es JEE ist oder oft nur reine Marketing Gags, das gilt aber auch fuer Spring.
Pooling an sich bringt schon Komplexitaet rein (Stateless, Mutable), welches konkrete Problem wuerde man damit loesen?
Ansonsten kann man immer mit einem Pool arbeiten, selber schreiben oder vorhandene Implementierungen nutzen wie zB. Pool – Overview
Wuerde mal anfangen ein minimales Spielprojekt anzulegen fuer einen ueblichen aber stark reduzierten Anwendungsfall, bestaetigt der Profiler wirklich das ein new teuer ist?
Vielleicht muss ich den Fall doch etwas konkreter beschreiben: Ich möchte einen REST Service entwickeln, der stark skalierbar ist. D.h. er soll unter hoher Last noch ein definiertes Verhalten an den Tag legen (nicht blockieren und langsam werden) und gut clusterbar sein. Eine JMS Nachricht kann entweder eine Lese- oder eine Speicheranweisung sein, hat also einen DB/Cachezugriff zur Folge. Die Idee mit den MDBs kam mir, weil ich im JEE Umfeld viel Erfahrung habe und ich mich hier eher zu Hause fühle, die Spring Frage kam jetzt erst mal aus Neugierde
Du sprichst die Kosten der Instanzerzeugung an, das Thema ist für mich eher zweitrangig. Mein Problem ist ja nicht dass ich ‚Instanzen wiederverwenden‘ möchte (was man optimalerweise eh nur mit Stateless Beans tun sollte), sondern dass ich (zur Laufzeit anpassbar) eine beliebige Anzahl an Consumern erzeuge, die parallel ihr Ding machen und aktiv die Queue abarbeiten. Natürlich könnte ich auch in Spring auf die Queue hören und für jeden Request eine Instanz meines Workers erstellen, die den Request bearbeitet. Wir reden hier von geschätzten 10.000 Requests die Stunde, wollen auch noch Luft nach oben. Vielleicht habe ich vor der Zahl auch zu viel Respekt und das ganze ließe sich wesentlich leichter lösen.
Leichtes OT: Natürlich haben wir alle unsere bevorzugten Techniken und Specs. Wenn es nach mir ginge dann würde ich die Anwendung mit Clojure, React und Hystrix erledigen, dafür ist das Umfeld hier dann aber doch zu konservativ
