java.net.SocketException: Connection reset

[Sangamesh_Unki1 (Sangamesh Unki)]

Hi All,

We have a requirement to access an open API HTTPS URL from webMethods using POST method. I am able to access the API using postman from our server. But while trying to connect from our webMethods, we are receiving the below error:

Java.net.SocketException: Connection reset

Any suggestions on resolving this please?

Thanks,

[Venkata_Kasi_Viswanath_Mugada1 (Kasi Mugada)]

Are you able to reach the server in the URL, from WITHIN your wM server? Check with a ping and traceroute(Linux) or tracert (Windows), so you can eliminate connectivity.

Generally, your laptop is more flexible than a wM environment.

KM

[reamon]

One guess is that the kex or cipher algorithms needed by the server are not in place in the JVM hosting wM IS.

Can you share details about the API URL? The version of wM IS and the JVM?

Compare the details sent by Postman with what is being sent from wM IS, presumably via pub.client:http. Are you sending the same HTTP headers?

[Sangamesh_Unki1 (Sangamesh Unki)]

Hi Reamon,

The API endpoint is in AZURE and currently no authentication policy is defined. No other restriction policy is defined. We were asked to use HTTPS url, Post method and one API version header to send requests to the API URL. We are able to send this request using postman from our server, and access the API.

But when we try to achieve the same from webMethods application using pub.client:http service, we are receiving only one error response everytime that is [java.net.SocketException: Connection reset].

Current WM IS we are using is 9.7 and Java Version : 1.7.0_65 (51.0).

[reamon]

Connection reset is usually an explicit action by one side or the other, or by a security proxy that does not like what is on the wire. Since you indicated you’re able to successfully use Postman on the same machine where wM IS resides, the best guess is the TLS interaction – the JVM possibly doesn’t support the TLS version or the algorithm(s) the Azure server wants. You might consider updating the JVM to 1.7.0_131-b31 or later which enable new TLS versions by default.

Again, this is just a guess as to what might be the issue.

[Sangamesh_Unki1 (Sangamesh Unki)]

Hi Reamon,

Thank you so much for the suggestions. It all makes sense.

For some reason, we are not able to get fixes using SUM. Is there any other way to update Java versions in webMethods?

Thanks,
Jitendra

[reamon]

SUM won’t provide JVM updates. You’ll need to obtain and apply that yourself.

[Holger_von_Thomsen]

Hi Sangamesh,

if possible and available, install a newer JVM version locally and then point the startup configuration of the servers to this local jvm copy outside of the wM installation.

Check setenv.bat, setenv.sh and/or wrapper.conf or custom_wrapper.conf files where jvm path might be specified.
Make sure to use the same major version (java 7 or java 8) which is already being used by your installation when not using official SAG JVM patches.

When using newer JVM major version (i.e. java 8 instead of java 7) without patching the installations accordingly with official SAG patches this might corrupt the whole installation.

For all wM releases prior to 10.x the standard support has ended meanwhile and for accessing latest fixes you will require an Extended Maintenance agreement for these releases. Without that you will only see latest published fixes before standard support ended.

Regards,
Holger

[Holger_von_Thomsen]

Hi Rob,

this depends on the wM release being used.
JVM updates are marked as CJP product fixes when available.
CJP stands for “Common Java Package”.

Regards,
Holger

[Sangamesh_Unki1 (Sangamesh Unki)]

Hi Holger,

Thanks for the information. We have upgraded our java version now to 1.7.0_301. But this has not resolved our connection reset issue. Any other suggestions on this please??

[Jaideep (Jaideep Pegu)]

Hi Unki,
Please enable the SSL debugging by setting the watt property “watt.config.systemProperties=mail.imap.partialfetch=true,javax.net.debug=ssl” and restart the IS. Try to access the HTTPS URL again and share the wrapper.log from the profiles/IS_default/logs directory. It might have some clue why reset is happening.

Thanks