Deze configuratie wordt toegepast op de WSO2 Enterprise Integrator 6.2.0 tot EI 6.6.0
Blokkeren versus niet-blokkeren:
Tijdens het doen van HTTP-aanroepen vanuit de Enterprise Integrator zijn er 2 manieren om de backend-services/apis aan te roepen. De ene is blokkerend en de andere is niet-blokkerend. Het verschil is dat wanneer u een backend-service aanroept in de niet-blokkerende modus, de verzoekthread niet wacht tot de onderliggende werkthread die de back-end aanroept een antwoord terugstuurt, terwijl in de blokkeermodus de verzoekthread zou worden geblokkeerd totdat de werkthread de backend-oproep voltooit en reageert.
Daarom adviseert WSO2, volgens hun best practices, om altijd de voorkeur te geven aan niet-blokkerend transport. Omdat dit beter voor prestatie- en resourcebeheer.
Waarom is blokkeren soms nodig?
Hoewel WSO2 aanraadt om zoveel mogelijk de niet-blokkerende modus te gebruiken, zijn er situaties waarin we de blokkerende modus moeten gebruiken. Een dergelijk scenario kan bijvoorbeeld zijn bij het omgaan met op JMS gebaseerde proxyservices. Als u in een op JMS gebaseerde proxy meerdere oproepen naar de backend-systemen wilt maken, moeten alle oproepen in de blokkeermodus staan. Dit wordt gedaan om de JMS-transacties bij te houden en het bericht zo nodig terug te halen.
Tijdens het blokkeren van oproepen staat WSO2 standaard slechts 2 gelijktijdige verbindingen per host toe. Als de ESB meer oproepen moet verzenden, moet elk verzoek in de rij blijven totdat er een verbinding beschikbaar is. Dit kan veel tijd in beslag nemen en kan er zelfs toe leiden dat oproepen mislukken, waardoor Connection Reset-fouten niet functioneert. De uitzondering die u in de logboeken ziet, kunt u hieronder bekijken:
Uitzondering:
java.net.SocketException: verbinding opnieuw instellen
op java.base/java.net.SocketInputStream.read (Onbekende bron)
op java.base/java.net.SocketInputStream.read (Onbekende bron)
op java.base/sun.security.ssl.SSLSocketInputRecord.read (onbekende bron)
op java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket (onbekende bron)
op java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord (onbekende bron)
op java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read (onbekende bron)
op org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
op org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
op org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
op org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
op org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
op org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
op org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
op org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
op org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
op org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
op org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
op org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
Wat moet u doen als er een fout optreedt?
Om dit probleem op te lossen, zijn er 2 eenvoudige dingen die u kunt doen.
Bewerk eerst in de directory <EI_HOME>/bin het bestand integrator.sh of integrator.bat . Voeg de volgende waarden eraan toe.
- -Dlst_t_core=200
- -Dlst_t_max=250
- -Dsnd_t_core=200
- -Dsnd_t_max=250
Hierdoor zal het aantal threads dat wordt gebruikt toenemen. Als deze waarden er niet zijn, kunt u ze gewoon definiëren. Deze eigenschappen zijn gerelateerd aan nHTTP- protocolconfiguraties.
Ten tweede kunt u de limiet van de defaultMaxConnectionsPerHost- parameterconfiguratie verhogen in het bestand <EI_HOME>/conf/axis2/axis2_blocking_client.xml . Als u bijvoorbeeld 100 gelijktijdige verbindingen per host moet instellen, kunt u de waarde van de parameter als volgt instellen:
< 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 >Nadat u beide wijzigingen hebt aangebracht, moet u de EI-instanties opnieuw starten.
Conclusie:
Door deze instellingen te wijzigen, verhoogt u het aantal threads en de standaardlimiet van de WSO2 EI-verbindingslimiet per host. Houd er rekening mee dat er ook een andere reden kan zijn waarom deze fout optreedt. Dus als de bovenstaande configuratie niet voor u werkt, is er mogelijk een ander onderliggend probleem. Het meest waarschijnlijke scenario in dat geval is dat er een verschil kan zijn in TLS-versies tussen de Enterprise Integrator en de backend.
Als u het gedoe van het onderzoeken van deze lange uitzonderingen en fouten wilt vermijden, bekijk dan onze Connext Go -oplossing die de Integration as a Service-oplossing biedt. Met de Connext Go kunt u rekenen op 24/7 volledige ondersteuning van Yenlo-experts om dergelijke problemen op te lossen tegen een vaste prijs per integration per maand.
