We regularly but randomly face the following issue with an API call. The only way we've found to get it to run for a few days is to restart the runtime service
What we have already done/explored :
Network : no issue found
API : It responds with a postman call
Connection timeout set to 5mn
Read timeout set to 2mn
xDI env information :
xDI designer : 5.3.10
Runtime Release Version 5.3.10
Remote Runtime version s21.0.0_20211013
Remote Scheduler version s20.0.0_20200214
Remote Command Line Utility version s21.0.0_20211013
Remote Common librairie version s20.5.0_20210225
Remote Actions version 21.1.0-SNAPSHOT
Remote API version s21.0.0_20211013
org.xml.sax.SAXException: Error on path: /Export2Test/TestService/TestPort/POST_creermodifiermethod/output/result
java.net.SocketTimeoutException: connect timed out
at com.indy.engine.actionCodes.XmlToWsdlActionCodeI$SimpleContentHandler.endElement(XmlToWsdlActionCodeI.java:704)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XML11NSDocumentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.indy.engine.actionCodes.XmlToWsdlActionCodeI.executeSimpleCode(XmlToWsdlActionCodeI.java:170)
at com.indy.engine.manager.ActionCodeExecutor.executeCode(ActionCodeExecutor.java:138)
at com.indy.engine.manager.ActionCodeExecutor.run(ActionCodeExecutor.java:265)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.net.SocketTimeoutException: connect timed out
at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:412)
at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:255)
at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:237)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.base/java.net.Socket.connect(Socket.java:609)
at java.base/sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:305)
at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:177)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:604)
at java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:266)
at java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:373)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:207)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1187)
at java.base/sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1071)
at java.base/sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1069)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:795)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1068)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:193)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1367)
at java.base/sun.net.www.protocol.http.HttpURLConnection$8.run(HttpURLConnection.java:1334)
at java.base/sun.net.www.protocol.http.HttpURLConnection$8.run(HttpURLConnection.java:1332)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:795)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1331)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:246)
at com.indy.engine.actionCodes.wsdl.HttpOperation.postInvoke(HttpOperation.java:629)
at com.indy.engine.actionCodes.wsdl.HttpOperation.invoke2(HttpOperation.java:696)
at com.indy.engine.actionCodes.wsdl.HttpOperation.invoke(HttpOperation.java:745)
at com.indy.engine.actionCodes.XmlToWsdlActionCodeI$SimpleContentHandler.invoke(XmlToWsdlActionCodeI.java:813)
at com.indy.engine.actionCodes.XmlToWsdlActionCodeI$SimpleContentHandler.closeOutputPart(XmlToWsdlActionCodeI.java:828)
at com.indy.engine.actionCodes.XmlToWsdlActionCodeI$SimpleContentHandler.endElement(XmlToWsdlActionCodeI.java:687)
... 12 more
Any help would be appreciated
Best Answer
A
Audric Frey
said
4 months ago
Hello,
If you have already changed the timeout option in the HTTP rest Metadata
You can try to modify it on the runtime configuration.
It is possible to launch the runtime with a java option that allows you to force a timeout on all http connections that remain unanswered. To activate it, you must modify the engineParameters.xml file of your runtime. You must uncomment and modify the javaConfiguration part of this file. The java option to use: <property name="sun.net.client.defaultReadTimeout" value="60000"/>
The timeout value is expressed in milliseconds (so in the example above it is a one-minute timeout). Afterwards, restart the runtime for the modification to be taken into account.
With this configuration, if the server does not respond, the "Call WebService" action will fail after one minute. The configuration will be applied to all http connections made by the runtime.
Kindly take the backup of engineParameters.xml file before modification.
1 Comment
A
Audric Frey
said
4 months ago
Answer
Hello,
If you have already changed the timeout option in the HTTP rest Metadata
You can try to modify it on the runtime configuration.
It is possible to launch the runtime with a java option that allows you to force a timeout on all http connections that remain unanswered. To activate it, you must modify the engineParameters.xml file of your runtime. You must uncomment and modify the javaConfiguration part of this file. The java option to use: <property name="sun.net.client.defaultReadTimeout" value="60000"/>
The timeout value is expressed in milliseconds (so in the example above it is a one-minute timeout). Afterwards, restart the runtime for the modification to be taken into account.
With this configuration, if the server does not respond, the "Call WebService" action will fail after one minute. The configuration will be applied to all http connections made by the runtime.
Beatrice.inthilith
Hi,
We regularly but randomly face the following issue with an API call. The only way we've found to get it to run for a few days is to restart the runtime service
What we have already done/explored :
xDI env information :
xDI designer : 5.3.10
Runtime Release Version 5.3.10
Remote Runtime version s21.0.0_20211013
Remote Scheduler version s20.0.0_20200214
Remote Command Line Utility version s21.0.0_20211013
Remote Common librairie version s20.5.0_20210225
Remote Actions version 21.1.0-SNAPSHOT
Remote API version s21.0.0_20211013
Any help would be appreciated
Hello,
If you have already changed the timeout option in the HTTP rest Metadata
You can try to modify it on the runtime configuration.
It is possible to launch the runtime with a java option that allows you to force a timeout on all http connections that remain unanswered. To activate it, you must modify the engineParameters.xml file of your runtime.
You must uncomment and modify the javaConfiguration part of this file.
The java option to use:
<property name="sun.net.client.defaultReadTimeout" value="60000"/>
The timeout value is expressed in milliseconds (so in the example above it is a one-minute timeout).
Afterwards, restart the runtime for the modification to be taken into account.
With this configuration, if the server does not respond, the "Call WebService" action will fail after one minute.
The configuration will be applied to all http connections made by the runtime.
Kindly take the backup of engineParameters.xml file before modification.
Audric Frey
Hello,
If you have already changed the timeout option in the HTTP rest Metadata
You can try to modify it on the runtime configuration.
It is possible to launch the runtime with a java option that allows you to force a timeout on all http connections that remain unanswered. To activate it, you must modify the engineParameters.xml file of your runtime.
You must uncomment and modify the javaConfiguration part of this file.
The java option to use:
<property name="sun.net.client.defaultReadTimeout" value="60000"/>
The timeout value is expressed in milliseconds (so in the example above it is a one-minute timeout).
Afterwards, restart the runtime for the modification to be taken into account.
With this configuration, if the server does not respond, the "Call WebService" action will fail after one minute.
The configuration will be applied to all http connections made by the runtime.
Kindly take the backup of engineParameters.xml file before modification.
1 person likes this
-
How to fix error "HikariPool-3 - Connection is not available, request timed out after 100005ms."
-
How to force the decimal separator by setting user.country java option?
-
All the deliveries failed
-
How to configure the scheduler for Sql Server database ? (having a specific schema name (not dbo))
-
[Error]: ClassNotFoundException
-
Error when installing xDI Runtime on Docker
-
Error when using quartz scheduler
-
Getting issue when trying to install xdi runtime on docker
-
[startdelivery] : error Caused by: javax.net.ssl.SSLHandshakeException: The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]
-
How to check runtime version ?
See all 12 topics