TOC

Gleichzeitige Strategien mit MDBs

Gleichzeitige Strategien mit MDBs

1. Einführung

Message Driven Beans, auch als „MDB“ bekannt, verarbeiten Nachrichten in einem asynchronen Kontext. Wir können die Grundlagen von MDB inthis article lernen.

In diesem Lernprogramm werden einige Strategien und bewährte Methoden zum Implementieren von Parallelität mithilfe von Message Driven Beans erläutert.

Wenn Sie mehr über die Grundlagen der Parallelität mit Java erfahren möchten, können Sie mithere beginnen.

Um MDBs und Nebenläufigkeiten besser nutzen zu können, müssen einige Überlegungen angestellt werden. It’s important to keep in mind that those considerations should be driven by the business rules and the needs of our application.

2. Thread-Pool optimieren

Das Optimieren des Thread-Pools ist wahrscheinlich das Hauptaugenmerk. Um die Parallelität gut nutzen zu können, müssen wirtune the number of MDB instances available to consume messages. Wenn eine Instanz mit der Bearbeitung einer Nachricht beschäftigt ist, können andere Instanzen die nächsten abholen.

DerMessageListener-Thread ist dafür verantwortlich, dieonMessage-Methode einer MDB auszuführen. Dieser Thread ist Teil desMessageListener-Threadpools. Dies bedeutet, dass er zusammengefasst und immer wieder verwendet wird. This pool also has a configuration that allows us to set the number of threads, which may impact the performance:

  • Durch das Festlegen einer kleinen Poolgröße werden Nachrichten langsam verarbeitet („MDB-Drosselung“).

  • Das Festlegen einer sehr großen Poolgröße kann die Leistung beeinträchtigen - oder überhaupt nicht funktionieren.

BeiWildfly können wir diesen Wert festlegen, indem wir auf die Verwaltungskonsole zugreifen. Die JMS-Funktion ist im Standard-Standalone-Profil nicht aktiviert. Wir müssen den Server mitfull profile starten.

Normalerweise greifen wir bei einer lokalen Installation überhttp://127.0.0.1:9990/console/index.html darauf zu. Danach müssen wir auf Configuration / Subsystems / Messaging / Server zugreifen, unseren Server auswählen und auf View klicken.

Wählen Sie die Registerkarte "Attribute", klicken Sie auf "Bearbeiten" und ändern Sie den Wert von "Thread Pool Max Size". Der Standardwert ist 30.

3. Optimieren der maximalen Sitzungen

Eine weitere konfigurierbare Eigenschaft, die Sie beachten sollten, istMaximum Sessions. Dies definiert die Parallelität für einen bestimmten Listener-Port. Normalerweise ist dies der Standardwert 1, aber durch Erhöhen dieses Werts kann die MDB-Anwendung skalierter und verfügbarer werden.

Wir können es entweder durch Anmerkungen oder durch.xml-Deskriptoren konfigurieren. Durch Anmerkungen verwenden wir@ActivationConfigProperty: 

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName=”maxSession”, propertyValue=”50”
    )
})

Wenn die gewählte Konfigurationsmethode.xml Deskriptoren ist, können wirmaxSession wie folgt konfigurieren: 


    
        maxSession
        50

4. Bereitstellungsumgebung

Wenn eine hohe Verfügbarkeit erforderlich ist, sollten Sie die MDB in einem Anwendungsservercluster implementieren. Auf diese Weise kann es auf jedem Server im Cluster ausgeführt werden, und viele Anwendungsserver können es gleichzeitig aufrufen, wodurch sich auch die Skalierbarkeit verbessert.

Für diesen speziellen Fall müssen wir eine wichtige Entscheidung treffen:

  • makeall servers in the cluster eligible to receive messages, wodurch die gesamte Rechenleistung genutzt werden kann, oder

  • Stellen Sie die Nachrichtenverarbeitung insequential manner by allowing just one server to receivethem at a time sicher

Wenn Sie einen Unternehmensbus verwenden, empfiehlt es sich, die MDB auf demselben Server oder Cluster wie das Busmitglied bereitzustellen, um die Messaging-Leistung zu optimieren.

5. Nachrichtenmodell und Nachrichtentypen

Obwohl dies nicht so klar ist wie das Festlegen eines anderen Werts für einen Pool, können das Nachrichtenmodell und der Nachrichtentyp einen der besten Vorteile der Verwendung von Parallelität beeinflussen: die Leistung.

Wenn Sie XML für einen Nachrichtentyp auswählen, z. B.the size of the message can affect the time spent to process it. Dies ist ein wichtiger Gesichtspunkt, insbesondere wenn die Anwendung eine große Anzahl von Nachrichten verarbeitet.

In Bezug auf das Nachrichtenmodellif the application needs to send the same message to a lot of consumers, a publish-subscribe model might be the right choice. Dies würde den Aufwand für die Verarbeitung der Nachrichten verringern und eine bessere Leistung liefern.

Um von einemTopic in einem Publish-Subscribe-Modell zu verbrauchen, können wir Anmerkungen verwenden: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Topic")

Auch hier können wir diese Werte im Bereitstellungsdeskriptor von.xmlkonfigurieren: 


    
        destinationType
        javax.jms.Topic

Wenn das Senden derselben Nachricht an viele Verbraucher nicht erforderlich ist, reicht das reguläre PTP-Modell (Point-to-Point) aus.

Um aus einer Warteschlange zu konsumieren, legen wir die Anmerkung wie folgt fest: 

@ActivationConfigProperty(
  propertyName = "destinationType",
  propertyValue = "javax.jms.Queue")

Wenn wir den Bereitstellungsdeskriptor von.xmlverwenden, können wir Folgendes festlegen: 


    
        destinationType
        javax.jms.Queue

6. Fazit

Wie bereits von vielen Informatikern und IT-Autoren festgestellt, nimmt die Geschwindigkeit der Prozessoren nicht mehr so ​​schnell zu. Damit unsere Programme schneller funktionieren, müssen wir mit der höheren Anzahl von Prozessoren und Kernen arbeiten, die heute verfügbar sind.

In diesem Artikel wurden einige bewährte Methoden erläutert, um die Parallelität mithilfe von MDBs optimal zu nutzen.

Related