Develop Reference

Calendar API calls begin to produce "SSL peer shut down"

I have a middleware (developped with Tibco ActiveMatrix BusinessWorks, but I don't think it's very important) that have been working for months, and suddently on 2020-10-17 started to fail on a high number of requests (around 8000) with the error:
javax.ws.rs.ProcessingException: javax.net.ssl.SSLException: SSL peer shut down incorrectly
Any idea why this error would suddently start occuring, and how to solve it ? Thanks in advance.
Full stacktrace:
Job-3158 Error in [BusinessProcesses/AgendasSecurises/Helpers/Gmail/Get Event.process/Get Event] Activity invocation failed at com.tibco.pe.plugin.Activity.postEval(Unknown Source) at com.tibco.pe.plugin.Activity.postEval(Unknown Source) at com.tibco.pe.core.TaskImpl.eval(Unknown Source) at com.tibco.pe.core.Job.a(Unknown Source) at com.tibco.pe.core.Job.k(Unknown Source) at com.tibco.pe.core.JobDispatcher$JobCourier.a(Unknown Source) at com.tibco.pe.core.JobDispatcher$JobCourier.run(Unknown Source) caused by: javax.ws.rs.ProcessingException: javax.net.ssl.SSLException: SSL peer shut down incorrectly at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:287) at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:252) at org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:701) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:228) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:697) at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:420) at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:316) at com.tibco.plugin.json.activities.RestActivity.doGet(RestActivity.java:485) at com.tibco.plugin.json.activities.RestActivity.doService(RestActivity.java:473) at com.tibco.plugin.json.activities.RestActivity$1.run(RestActivity.java:418) at com.tibco.pe.util.ThreadPool$ThreadPoolThread.run(Unknown Source) Caused by: javax.net.ssl.SSLException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.readV3Record(InputRecord.java:596) at sun.security.ssl.InputRecord.read(InputRecord.java:532) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:990) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1388) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1416) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1400) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:352) at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:399) at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:285) ... 13 more

This is very likely that something changed on the server side on the mentioned date.
It could be a change of certificate or some changes that require use of a robust encryption library (for example TLS 1.2 might now be mandatory).
If you are using a recent version of BusinessWorks TLS 1.2 should be enabled by default. If you are using older versions (6.3.x) you may have to edit the bwappnode.tra file with the following :
java.extended.properties=-Xmx1024m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -Dhttps.protocols=TLSv1.1,TLSv1.2
You can use the elements from the following TIBCO KB to get more trace and debug your issue:
https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-44615

Java Spring Rest Client Connection Reset Error

I have implemented rest client to consume a rest webservice using below code,
Client client = Client.create();
client.addFilter(new HTTPBasicAuthFilter(USERNAME,PASSWORD));
WebResource webResource = client.resource(URL);
ClientResponse clientResponse = webResource.type("application/json").accept("application/json").post(ClientResponse.class, REQUEST);
But I am facing below error,
com.sun.jersey.api.client.ClientHandlerException: java.io.IOException: Connection reset by peer
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
at com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105)
at com.sun.jersey.api.client.Client.handle(Client.java:652)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:570)
at org.springframework.jms.listener.adapter.MessageListenerAdapter.onMessage(MessageListenerAdapter.java:339)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:241)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1056)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1048)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.readv0(Native Method)
at sun.nio.ch.SocketDispatcher.readv(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.read(IOUtil.java:278)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:440)
at weblogic.socket.NIOInputStream.readInternal(NIOInputStream.java:148)
at weblogic.socket.NIOInputStream.read(NIOInputStream.java:90)
at weblogic.socket.NIOInputStream.read(NIOInputStream.java:73)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:310)
at weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:232)
at weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:554)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:688)
at weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:41)
at weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:1545)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
... 17 more
But If I restart the server this issue is not appearing for some time and again it appears. Has anyone faced similar issue ? I don't get any proper solution when googled.
I am using Weblogic Server in client side and rest service is also deployed in remote weblogic server.
EDIT- When I tried with curl command in the same server where it is throwing this error, it is retrieving the results.

Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.
check here

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

I am launching a JNLP downloaded from my web application.
After being prompted with a Java Security Warning prompt, the application can run successfully if the user response is within 2-3 seconds. However, if the user took more than 3 seconds to respond to the Java Security Warning prompt, the application fails to run with error with the following socket exception:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during
handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake
(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake
(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake
(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect
(HttpsClient.java:563)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:1300)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream
(HttpsURLConnectionImpl.java:254)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable
(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown
Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
... 19 more
Java Security Warning
Exception
Additional Info: I have checked the ports and they were pointing on the correct port numbers and TLS value also matched. The certificates were also added under cacerts.
Question: What causes the exception when response to the security prompt reaches more than 3-5 seconds? and how can I avoid the mentioned exception(possibly increase the waiting time)?
Actions done:
1. Add connectionTimeout attribute in Tomcat connector, but still, after 5 seconds of waiting time to respond to the Java Security Warning, the application still fails to launch.

This is most easily controlled by the https.protocols system property. This is how you are able to control what the factory method returns. Set to "TLSv1" for example.
It leads to problems when you want to use two protocols instead of one. For example, SSLv3 and TLSv1. This -Dhttps.protocols=TLSv1,SSLv3 will lead to exceptions if you try to connect either SSLv3 or TLSv1.
Please check this answer.
How to make Java 6, which fails SSL connection with "SSL peer shut down incorrectly", succeed like Java 7?

I was facing the same problem, then I switched from JRE1.7 to JRE1.8 of course for reason TLS1.2 More references

Https CXF timeout

I'm trying to use a WebService of a payment gateway which uses HTTPS as protocol and i'm using an apache cxf client.
The problem I'm getting timeout to all my requests, but when I use curl to the same WebService I get the response without any problems.
When i log into admin area of the payment gateway, all my tries are there without any errors, so i could say that the problem is somewhere in response.
The stacktrace are down below.
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:510)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:343)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:295)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:75)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at com.sun.proxy.$Proxy1074.authorize(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
Caused by: java.net.SocketTimeoutException: Read timed out
at jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
at jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:422)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:460)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:863)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:820)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:224)
at weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:148)
at weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:468)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:401)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
at weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:1005)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1509)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1467)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1375)

You might want to change the receiveTimeout setting from Apache CXF src and replace the existing cxf-rt-transports-http-version.jar in your server.
See the instructions from Wildfly 8.2/undertow read time out

Check if you are behind web proxy,that's why it working in curl but not through through Apache CXF.

CXF Timeout not working

I created a web service client using cxf configured through Spring as shown below:
<!-- HTTP Conduit -->
<http-conf:conduit name="*.http-conduit">
<http-conf:client ConnectionTimeout="30000"
ReceiveTimeout="30000" />
</http-conf:conduit>
<!-- Client Proxies -->
<jaxws:client name="wsClient" serviceName="..."
serviceClass="..."
address="..." wsdlLocation="...">
</jaxws:client>
Now when the service is up, everything's working OK, But the problem is, when the service is down timeout values in the HTTPConduit are being ignored and I get the following error after 1 second:
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:136)
Caused by: java.net.ConnectException: Tried all: '1' addresses, but could not connect over HTTP to server: '192.168.80.55', port: '24004'
at weblogic.net.http.HttpClient.openServer(HttpClient.java:333)
at weblogic.net.http.HttpClient.openServer(HttpClient.java:425)
at weblogic.net.http.HttpClient.New(HttpClient.java:252)
at weblogic.net.http.HttpURLConnection.connect(HttpURLConnection.java:213)
at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:279)
at org.apache.cxf.transport.http.HTTPCon2014-08-30 13:06:59 ERROR: javax.xml.ws.WebServiceException: Could not send Message.
Any clue why the consumer doesn't stay for the timeout duration before raising this error?

Timeout does not apply when the server is 'down'.
The ConnectionTimeout is how much to wait before connecting.
The ReceiveTimeout is how much to wait before receving a response.
In your case, there is no server listening on that port, so when your clients try to connect, the clients fails immediatly.

What do you mean by 'down'? Service responds with a 404? Closed port (connection refused)? Host is down (no connection possible due to timeout)?