Warum und wann JMS-Nachrichtennutzdaten nach Referenz übergeben werden

Wenn große Objektnachrichten oder Bytenachrichten gesendet werden, können die Kosten für die Speicher- und Prozessornutzung, die durch das Serialisieren, Deserialisieren und Kopieren der Nachrichtennutzdaten entstehen, beträchtlich sein. Wenn Sie die Eigenschaften für die Übernahme von Nachrichtennutzdaten nach Referenz in einer Verbindungsfactory oder Aktivierungsspezifikation aktivieren, teilen Sie dem Standard-Messaging-Provider dadurch mit, die Spezifikation JMS 1.1 zu überschreiben und das Kopieren der Daten nach Möglichkeit einzuschränken oder zu umgehen.

Hintergrund

Die Spezifikation JMS 1.1 legt fest, dass Objektnachrichten nach Wert übergeben werden. Das bedeutet, dass ein JMS-Provider, wie z. B. der Standard-Messaging-Provider in WebSphere Application Server, eine Kopie des Objekts in ObjectMessage erstellen muss, wenn das Objekt in den Nachrichtennutzdaten festgelegt wird, um Vorsorge zu treffen, falls die Clientanwendung das Objekt nach der Definition ändert. In der Praxis bedeutet dies, das Objekt zu serialisieren, da es keine andere vollkommen sichere Möglichkeit gibt, eine Kopie zu erstellen. Die Spezifikation legt außerdem fest, dass der JMS-Provider eine Kopie dieser Daten erstellen und zurückgeben muss, wenn eine Konsumentenanwendung die Daten aus der Nachricht abruft.

Wenn Sie die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" aktivieren, können Sie unter Umständen Speicher- und Leistungsverbesserungen beim JMS-Messaging erzielen.

Vorsicht:
  • Die Teile der JMS-Spezifikation, die von diesen Eigenschaften umgangen werden, werden definiert, um die Integrität der Nachrichtendaten zu gewährleisten.
  • Alle JMS-Anwendungen, die diese Eigenschaften verwenden, müssen die Regeln, die weiter hinten in diesem Abschnitt detailliert beschrieben sind, strikt einhalten, da die Datenintegrität ansonsten nicht gewährleistet werden kann.
  • Sie müssen die Informationen in diesem Artikel sorgfältig lesen und verstehen, bevor Sie diese Eigenschaften aktivieren.
Für die Übergabe der Nachrichtennutzdaten nach Referenz definieren Sie die folgenden Eigenschaften in den Verbindungsfactorys und Aktivierungsspezifikationen:
producerDoesNotModifyPayloadAfterSet (für Verbindungsfactorys) oder forwarderDoesNotModifyPayloadAfterSet (für Aktivierungsspezifikationen)
Wenn diese Eigenschaft aktiviert ist, werden Objekt- oder Bytenachrichten, die von der Verbindungsfactory erzeugt oder über die Aktivierungsspezifikation weitergeleitet werden, nicht kopiert, wenn sie in der Nachricht festgelegt werden, und nur dann serialisiert, wenn es unbedingt erforderlich ist. Anwendungen, die solche Nachrichten senden, dürfen die Daten, nachdem sie in die Nachricht gestellt wurden, nicht mehr ändern.
consumerDoesNotModifyPayloadAfterGet
Wenn diese Eigenschaft aktiviert ist, werden Objektnachrichten, die über die Verbindungsfactory oder Aktivierungsspezifikation empfangen werden, nur serialisiert, wenn es unbedingt erforderlich ist. Die aus diesen Nachrichten abgerufenen Daten dürfen von Anwendungen nicht geändert werden.

Potenzielle Vorteile der Übergabe von Nachrichtennutzdaten nach Referenz

In der folgenden Tabelle sind die Bedingungen beschrieben, unter denen Sie durch die Aktivierung der Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" Leistungsverbesserungen erzielen können. Für diese Tabelle gelten die folgenden Voraussetzungen:
  • Ihre JMS-Anwendungen entsprechen den Regeln, die im nächsten Abschnitt dieses Artikels beschrieben werden.
  • Ihre Nachrichtenerzeuger- und -konsumentenanwendungen werden zusammen mit der Messaging-Engine, die das von diesen Anwendungen verwendete Ziel beinhaltet, in derselben JVM (Server) ausgeführt.
Anmerkung:
  • Wenn Ihre Anwendungen in unterschiedlichen Servern oder auf der Plattform z/OS (auf der WebSphere Application Server in mehreren JVMs ausgeführt wird) ausgeführt werden, werden Objektnachrichten serialisiert, und es können keine Leistungsverbesserungen für diese Nachrichten erzielt werden. Für Bytenachrichten können trotzdem Verbesserungen erzielt werden.
  • Es gibt zahlreiche interne Laufzeitbedingungen, die zu einer Serialisierung Ihrer Nachrichten führen können, sodass Sie durch die Aktivierung der Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" nur geringfügige oder gar keine Leistungsverbesserungen erzielen, selbst wenn Ihre Konfiguration alle Bedingungen erfüllt.
Tabelle 1. Konfigurations- und Laufzeitfaktoren, die bestimmen, welche Daten kopiert werden, wann und welche Leistungsverbesserungen erzielt werden. In der ersten Spalte ist der Grad potenzieller Leistungsvorteile angegeben. Die zweite Spalte enthält die Konfigurations- und Laufzeitereignisse der potenziellen Vorteile. Die dritte Spalte enthält Informationen dazu, welche Daten kopiert werden und wann, basierend auf den Konfigurations- und Laufzeitereignissen der potenziellen Vorteile.
Grad der potenziellen Leistungsverbesserung Konfigurations- und Laufzeitereignisse Zeitpunkt der Datenkopie
Keine potenziellen Verbesserungen

Die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" sind nicht aktiviert (Standardverhalten).

Die Objektnachrichtendaten werden kopiert, sobald sie in der Nachricht festgelegt sind und wenn sie aus der Nachricht abgerufen werden.

Die Bytenachrichtendaten werden kopiert, sobald sie in der Nachricht festgelegt sind und wenn sie aus der Nachricht abgerufen werden.

Gewisse potenzielle Verbesserungen
Die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" sind aktiviert und eine oder beide der folgenden Bedingungen treffen zu:
  • Die gesendete oder empfangene Nachricht ist verarbeitet.
  • Der Konsument ist nicht verfügbar, wenn die Nachricht erzeugt wird.

[AIX Solaris HP-UX Linux Windows][IBM i]Die Objektnachrichtendaten werden nur bei Bedarf kopiert.

Die Bytenachrichtendaten werden nur bei Bedarf kopiert.

Maximale potenzielle Verbesserungen
Die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" sind aktiviert und beide der folgenden Bedingungen treffen zu:
  • Weder die gesendete oder die empfangene Nachricht ist verarbeitet.
  • Der Konsument wartet auf die Nachricht, wenn diese erzeugt wird (z. B., wenn der Konsument eine nachrichtengesteuerte Bean (MDB, Message-Driven Bean) ist.

[AIX Solaris HP-UX Linux Windows][IBM i]Die Objektnachrichtendaten werden möglicherweise nie kopiert.

Die Bytenachrichtendaten werden nur bei Bedarf kopiert.

Regeln, die Ihre JMS-Anwendungen einhalten müssen

Die Teile der JMS-Spezifikation, die von den Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" umgangen werden, werden definiert, um die Integrität der Nachrichtendaten zu gewährleisten. Wenn Ihre JMS-Anwendungen die in der folgenden Tabelle beschriebenen Regeln einhalten, können Sie die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" in den Verbindungsfactorys und Aktivierungsspezifikationen, die von den Anwendungen verwendet werden, bedenkenlos aktivieren.

Wenn Sie die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" für JMS-Anwendungen aktivieren, die diese Regeln nicht einhalten, kann die Integrität der Nachrichtendaten gefährdet sein.

Tabelle 2. Regeln, die Ihre JMS-Anwendungen einhalten müssen, nach Anwendungstyp. In der ersten Spalte sind die JMS-Anwendungstypen aufgelistet. Die zweite Spalte enthält die Regeln, die die JMS-Anwendung einhalten muss.
Anwendungstyp Regeln
JMS-Erzeugeranwendung

Eine JMS-Erzeugeranwendung, die Objektnachrichten sendet, darf das Objekt nicht ändern, nachdem sie es in den Nutzdaten der Nachricht festgelegt hat.

Eine JMS-Erzeugeranwendung, die Bytenachrichten sendet, muss die folgenden Regeln einhalten:
  • Sie muss Daten in einem einzigen Aufruf von writeBytes(byte[]) in die Nachricht schreiben.
  • Sie darf die Bytefeldgruppe nicht mehr ändern, nachdem sie in die Nachricht geschrieben wurde.
JMS-Konsumentenanwendung

Eine JMS-Konsumentenanwendung, die Objektnachrichten empfängt, darf die Nutzdaten, die sie aus der Nachricht abruft, nicht ändern.

JMS-Weiterleitungsanwendung
Anmerkung: Eine JMS-Weiterleitungsanwendung empfängt eine Nachricht (über eine Verbindungsfactory bzw. eine Aktivierungsspezifikation, falls die Anwendung eine nachrichtengesteuerte Bean (MDB, Message-driven Bean) ist, und sendet das Nachrichtenobjekt anschließend an ein anderes Ziel.
Eine JMS-Weiterleitungsanwendung, die die Nutzdaten der empfangenen Nachricht durch neue Nutzdaten ersetzt, muss die folgenden Regeln einhalten:
  • (Bei Objektnachrichten) Sie darf das Objekt nicht mehr ändern, nachdem sie es in den Nutzdaten der Nachrichten festgelegt hat.
  • (Bei Bytedaten):
    • Sie muss Daten in einem einzigen Aufruf von writeBytes(byte[]) in die Nachricht schreiben.
    • Sie darf die Bytefeldgruppe nicht mehr ändern, nachdem sie in die Nachricht geschrieben wurde.

Serialisierung der Objektnachrichten sicherstellen

Unter normalen JMS-Messaging-Bedingungen (d. h., wenn die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" nicht aktiviert sind) werden die Daten in einer Objektnachricht serialisiert, sobald das Objekt an das Messaging-System übergeben wird, z. B. in set oder send. Wenn die Nachrichtennutzdaten nicht serialisiert werden können, wird unverzüglich eine Ausnahmenachricht an die Clientanwendung zurückgegeben.

Wenn die Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" aktiviert sind, werden die Nachrichtennutzdaten von der Clientanwendung ohne den Versuch einer Serialisierung akzeptiert. Wenn das System später feststellt, dass die Daten nicht serialisiert werden können, kann es die Clientanwendung, die die Nachricht gesendet hat, nicht mehr darüber informieren, und weil die Daten nicht serialisierbar sind, kann das System die vollständige Nachricht auch weder permanent speichern noch übertragen. Die Nachrichten und ihre Eigenschaften werden gespeichert, aber die Benutzerdaten in der Nachricht (die Nutzdaten) können nicht gespeichert werden und werden verworfen. Falls Serialisierungsprobleme auftreten, wenn das System versucht, eine Objektnachricht für eine Mediation in einen Datengraphen zu konvertieren, werden die Nachrichtennutzdaten verworfen, und die Mediation empfängt eine Nachricht, in der der Datenwert auf null gesetzt ist.

Wenn Ihre Daten nicht serialisiert werden können, gehen sie verloren. Deshalb sollten Sie Ihre Konfiguration zuerst ohne Aktivierung der Eigenschaften für die "Übergabe von Nachrichtennutzdaten nach Referenz" testen, um sicherzustellen, dass alle Daten, die an das System gesendet werden, serialisierbar sind.

Wenn das System feststellt, dass eine Objektnachricht nicht serialisiert werden kann, schreibt es die folgende Fehlernachricht (JMS_IBM_ExceptionMessage) in die Datei SystemOut.log. Die in der folgenden Beispielnachricht enthaltene Variable "{0}" wird zur Laufzeit durch den Klassennamen des fehlerhaften Objekts ersetzt:
Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
CWSIK0200E: Es wurde ein Objekt der Klasse "{0}" in den Nachrichtennutzdaten festgelegt, aber das Objekt kann nicht serialisiert werden.
Erläuterung: Es wurde eine Objektnachricht, für die das Flag producerDoesNotModifyPayloadAfterSet in der zugehörigen Verbindungsfactory aktiviert ist, mit Nutzdaten gesendet, die vom System nicht serialisiert werden konnten. Die Nachrichtendaten sind verloren gegangen.
Aktion: Inaktivieren Sie producerDoesNotModifyPayloadAfterSet in der Verbindungsfactory. Wenn Sie das Flag inaktivieren, empfängt die JMS-Anwendung, die das Objekt in der Nachricht festlegt, unverzüglich alle Serialisierungsausnahmen.
Die folgenden Ausnahmeeigenschaften werden verwendet, um anzuzeigen, dass ein Datenobjekt nicht serialisiert werden kann und verworfen wird. JMS-Anwendungen können über die Eigenschaften JMS_IBM_Exception feststellen, was geschehen ist. Mediationen können über die Eigenschaften JMS_IBM_Exception und SI_Exception feststellen, was geschehen ist.
JMS_IBM_ExceptionReason
SIRCConstants.SIRC0200_OBJECT_FAILED_TO_SERIALIZE
JMS_IBM_ExceptionTimestamp
Die Uhrzeit, zu der die Serialisierung des Objekts fehlgeschlagen ist im Format System.currentTimeMillis().
JMS_IBM_ExceptionMessage
Nachricht CWSIK0200E (siehe die Beschreibung oben)
SI_ExceptionReason
SIRC0200_OBJECT_FAILED_TO_SERIALIZE
SI_ExceptionTimestamp
Die Uhrzeit, zu der die Serialisierung des Objekts fehlgeschlagen ist im Format System.currentTimeMillis().
SI_ExceptionInserts
Eine Zeichenfolgefeldgruppe mit einem Eintrag. Der Eintrag enthält den Klassennamen des Objekts.
Anmerkung: Die wahrscheinlichste Erläuterung für die Tatsache, dass Ihre Datenobjekte nicht serialisiert werden konnten, ist die, dass Sie Ihre eigenen Methoden writeObject() oder writeExternal() geschrieben und nicht jede Option (z. B. Ausnahmen des Typs NullPointer oder ArrayIndexOutOfBounds) getestet haben.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjn_passbyref
Dateiname:cjn_passbyref.html