mehrere MDB-Listener lesen in derselben Warteschlange

Question

Ich habe eine Anforderung, mehrere MDB-Listener zu implementieren, die eine einzelne Warteschlange überwachen. Wenn die Belastung der Warteschlange zunimmt, reicht ein Listener nicht aus, um diese Belastung zu bewältigen. Ich würde gerne wissen, wie wir das am besten erreichen können.

a. Ich kann ähnliche MDB-Klassen erstellen und sie auf dem Websphere-Server bereitstellen. b. Irgendeine andere Weise, irgendeine Konfiguration verwendend?

Könnten Sie bitte den richtigen Ansatz angeben, als ob es möglich ist, die Listener dynamisch zu konfigurieren und sie bei Bedarf zu aktivieren oder es gibt nur einen Wegpunkt (a), um dies zu erreichen?

Answer 1

Sie verpassen einen entscheidenden Punkt. Es ist der Container, der eine oder mehrere Beans instanziiert, um die Anfrage des Clients zu bearbeiten. Die ganze Welt der Enterprise-Beans hat Skalierbarkeit als Kernpunkt.

Im Grunde brauchen Sie nichts anderes zu tun, als Ihre Bean zu entwerfen und zu implementieren. Der Container erledigt den Rest.

Answer 2

Wenn Sie MDBs wie in JEE-Spezifikation unter Verwendung der @MessageDriven Annotation definiert verwenden, ist es Aufgabe des Servercontainers, die tatsächliche Instanziierung und Skalierung dieser Beans zu verwalten. Ich bin mit Websphere nicht so vertraut, aber die meisten Server haben eine Vorstellung von EJB-Pooling, das grob in Thread-Pool übersetzt wird - was eine parallele Ausführung von Out-of-the-Box ermöglicht. Auf diese Weise verfügt der Server über eine Reihe von Instanzen, die die Nachrichten in Ihrer Warteschlange verarbeiten können. Jede Bean-Instanz ist nur für die Zeit aktiv, die für die Ausführung der Methode onMessage erforderlich ist. Danach wird sie bereinigt und in die Warteschlange zurückgestellt. Nehmen wir an, Sie haben einen Pool von MDBs mit der Größe 20. Wenn Sie mehr als 20 Nachrichten in der Warteschlange haben, verwendet der Server alle verfügbaren Instanzen und verarbeitet gleichzeitig 20 Nachrichten.
In Wildfly/JBoss zum Beispiel verwalten Sie Ihre EJB-Pools mit dem EJB-Subsystem und den entsprechenden Pool-Einstellungen.

<subsystem xmlns="urn:jboss:domain:ejb3:4.0"> 
    <!--omitted for brevity... --> 
    <mdb> 
     <resource-adapter-ref resource-adapter-name="${ejb.resource-adapter-name:activemq-ra.rar}"/> 
     <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/> 
    </mdb> 
    <pools> 
     <bean-instance-pools> 
      <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> 
     </bean-instance-pools> 
    </pools> 
    <!--omitted for brevity... --> 

Hier geben wir, dass Message Driven Beans einen Pool verwenden soll mdb-strict-max-pool benannt, die seine Größe von der Anzahl der CPUs auf unserem System leitet. Sie können auch absolute Werte angeben, z. max-pool-size="20"

All dies ist nur relevant, wenn Sie die Warteschlange auf einer einzelnen Serverinstanz ausführen. Wenn Sie wirklich eine nachrichtenintensive Anwendung ausführen, ist es wahrscheinlich, dass Sie eine verteilte Nachrichtenübermittlung mit dediziertem Nachrichtenbroker und mehreren Verarbeitungsinstanzen benötigen. Während viele Server solche Szenarien unterstützen (z. B. Wildfly ActiveMQ-Cluster), ist dies ein wirklich Thema für eine weitere Diskussion.

Weitere Informationen finden Sie unter MDB tutorial und Ihre Server-Dokumentation.
Happy Hacking.