Diese Konfiguration wird für den WSO2 Enterprise Integrator 6.2.0 bis EI 6.6.0 angewendet
Blockierend vs. nicht-blockierend:
Bei HTTP-Aufrufen vom Enterprise Integrator gibt es zwei Möglichkeiten, die Backend-Dienste/APIs aufzurufen. Eine ist blockierend und die andere ist nicht-blockierend. Der Unterschied liegt darin, dass beim Aufrufen eines Backend-Dienstes im nicht blockierenden Modus der Request-Thread nicht wartet, bis der zugrunde liegende Worker-Thread, der das Backend aufruft, eine Antwort sendet. Im blockierenden Modus hingegen wird der Request-Thread blockiert, bis der Worker-Thread den Backend-Aufruf abgeschlossen hat und antwortet.
Aus diesem Grund empfiehlt WSO2 in den Best Practices, dass wir immer den nicht-blockierenden Transport bevorzugen sollten. Denn das ist hinsichtlich der Performance und des Ressourcenmanagements besser.
Warum ist manchmal eine Sperrung notwendig?
Obwohl WSO2 empfiehlt, den nicht-blockierenden Modus so oft wie möglich zu verwenden, gibt es Situationen, in denen wir den blockierenden Modus verwenden müssen. Ein derartiges Szenario kann beispielsweise im Zusammenhang mit JMS-basierten Proxy-Diensten auftreten. Wenn Sie in einem JMS-basierten Proxy mehrere Aufrufe an die Backend-Systeme senden möchten, müssen alle Aufrufe im blockierenden Modus erfolgen. Dadurch können die JMS-Transaktionen nachverfolgt werden, und die Nachricht kann bei Bedarf zurückgesetzt werden.
WSO2 lässt bei blockierenden Aufrufen standardmäßig nur 2 gleichzeitige Verbindungen pro Host zu. Wenn der ESB weitere Aufrufe senden muss, muss jede Anfrage in der Warteschlange bleiben, bis eine Verbindung verfügbar ist. Das kann lange dauern und sogar dazu führen, dass Aufrufe fehlschlagen und Fehler beim Zurücksetzen der Verbindung ausgelöst werden. Die Ausnahme, die Sie in den Protokollen sehen werden, ist nachfolgend dargestellt:
Ausnahme:
java.net.SocketException: Connection reset
at java.base/java.net.SocketInputStream.read(Unknown Source)
at java.base/java.net.SocketInputStream.read(Unknown Source)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(Unknown Source)
at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(Unknown Source)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)Was ist zu tun, wenn ein Fehler auftritt
Zur Lösung dieses Problems können Sie 2 simple Maßnahmen ergreifen.
Bearbeiten Sie zuerst im Verzeichnis <EI_HOME>/bin die Datei integrator.sh oder integrator.bat. Fügen Sie darin die folgenden Werte ein.
- -Dlst_t_core=200
- -Dlst_t_max=250
- -Dsnd_t_core=200
- -Dsnd_t_max=250
Dadurch wird die Anzahl der verwendeten Threads erhöht. Wenn diese Werte nicht vorhanden sind, können Sie sie einfach definieren. Diese Eigenschaften beziehen sich auf nHTTP- Protokollkonfigurationen.
Zweitens können Sie das Limit der Parameterkonfiguration defaultMaxConnectionsPerHost in der Datei <EI_HOME>/conf/axis2/axis2_blocking_client.xml erhöhen. Wenn Sie z. B. 100 gleichzeitige Verbindungen pro Host einstellen müssen, können Sie den Wert des Parameters wie folgt festlegen:
< transportafzender class = "org.apache.axis2.transport.http.CommonsHTTPTransportSender" naam = "http" >
< parameter naam = "PROTOCOL" >HTTP/1.1</ parameter >
< parameter naam = "Transfer-Encoding" >geknakte</ parameter >
< parameter naam = "cacheHttpClient" >true</ parameter >
< parameter naam = "defaultMaxConnectionsPerHost" >100</ parameter >
</ transportsender >Nachdem Sie beide Änderungen vorgenommen haben, müssen Sie die EI-Instanzen neu starten.
Fazit:
Wenn Sie diese Einstellungen ändern, erhöhen Sie die Anzahl der Threads und das Standardlimit für das WSO2-EI-Verbindungslimit pro Host. Aber bedenken Sie bitte, dass es auch andere Gründe für diesen Fehler geben kann. Wenn die oben beschriebene Konfiguration bei Ihnen nicht funktioniert, liegt möglicherweise ein anderes Problem vor. Das wahrscheinlichste Szenario in diesem Fall ist, dass es Unterschiede in den TLS-Versionen zwischen Enterprise Integrator und dem Backend geben kann.
Wenn Sie sich die Mühe ersparen möchten, diese langen Ausnahmen und Fehler zu untersuchen, sehen Sie sich unsere Connext Go Lösung an, die die Lösung „Integration-as-a-Service“ bietet. Mit Connext Go können Sie rund um die Uhr auf den umfassenden Support von Yenlo-Experten zählen, die sich um solche Probleme kümmern – zu einem Festpreis pro Integration und Monat.
