I have a web service hosted on IIS on windows machine. Everything went fine until I upgraded Java to JRE 8u65.
Now it is throwing the below exception on invoking the web service.
Exception in thread "main" java.net.SocketException: Unexpected end of
file from server at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown
Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown
Source)
Note : Previously I was using JRE 8u60. Any help in this regard is really helpful.
Thanks in advance!
The stacktrace you have shown us comes from a Java client for your web service. What is saying is that the server has closed the network connection before sending an HTTP response.
There is no evidence in this stacktrace to say why the web service did that. The evidence is probably in the service logs.
Related
I have a web service running on a remote server and I wrote a client program to consume its services. The client program uses client stubs that were generated from a .wsdl file using the wsimport command. I am accessing the server via a proxy and in my program I tell the JVM to communicate via the proxy by setting the system properties "proxySet", "proxyPort" and "proxyHost", to true, and the corresponding port and address of the proxy respectively; which works fine. In addition, I'm also connecting via SSL, and the server certificate is signed by some other CAs, and in my case I needed to import the certificate to the trustore cacerts; which also works well. However I am not able to access the web service with the URL I specify in my program, though it can be accessed with a browser. below is the stack trace of my program:
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.io.IOException: Server returned HTTP response code: 500 for URL: https://webservicesimp.companyName.com/ReportingService
java.io.FileNotFoundException: https://webservicesimp.companyName.com/ReportingService?wsdl
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
at javax.xml.ws.Service.<init>(Unknown Source)
at com.conpanyName.xml.companyName.enterprise.report.v1.enterprisereportingservice_1.ReportingService.<init>(ReportingService.java:50)
at WebServices.<init>(WebServices.java:33)
at ERSWebServiceRunner.main(ERSWebServiceRunner.java:37)
Any help is appreciated... Thanks
I am testing a webservice and it works fine in SOAP UI tool.
Now I am writing a webservice client in java to test same. I executed the wsimport command and generated the required classes.
The issue is when I am calling the service it displays the following message in console. It seems the server is trying to redirect but redirection is failing. I am doubting there may be issue with http/https OR GET/POST methods but not sure how to fix.
Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 302: Found
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
Please suggest.
Regards,
Arun
After more analysis and change I am able to fix this issue. As I doubted the cause was redirection from http to https.
This post helped: Calling web service that sits on a load balancer with jax-ws returns at http status of 302, but when I use SoapUI it works fine
Regards,
Arun
I have a REST service and some clients get a "Connection reset" error. But SOAP is stateless, so why doesn't it just simply reconnect and resend the request? It actually sends multiple messages in my use case, but the very first fails, and that is just to get some config data from the server. Is this something I need to configure? Should the client programmatically try to resend the message? Some users tried multiple times with the same result.
It never happened in the last years but now I get some reports of this problem.
The client uses in implementation of javax.xml.ws.Service, not just a raw socket. But even though I use JAX I get the low level error. It is wrapped by a WebServiceException, but that doesn't really help me fixing this problem.
The clients all use Java 8. It's either Update 66 or Update 74.
I am not able to reproduce the problem myself, I only have log files from users.
Here's the complete stack trace:
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
at com.sun.proxy.$Proxy31.getLimits(Unknown Source)
at xxxxxxxxxxxxx.SOAPServerAdapter.connect(Unknown Source)
at xxxxxxxxxxxxxxxxxxxx(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
... 18 more
It turned out it was about IPv4 and IPv6. I don't have enough knowledge to give a perfect answer but I can post here what they told me. Maybe this helps other devs/users who have the same problem.
So some clients have unexpected connection resets and it's not about server load as it usually is.
If the ISP of the client tries to get away from IPv4 they will give each user a unique IPv6 address (note that the ISP might do this gradually). They do not really have an IPv4 address per client any more, other than the IPv4 used locally, since most still use something like 192.168.0.0/24 for their LAN.
Instead of classic IPv4 they use some transaction mechanism (e.g. Dual-Stack Lite). Those clients to not have direct access to the IPv4 internet. So if your server only supports IPv4 then they might experience similar problems you get when they use a proxy. They encapsulate IPv4 packets within IPv6 packets for some parts of the communication. From Wikipedia: "The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet."
I don't really know what's going wrong here. Maybe the NAT runs out of addresses / ports or something like that. Or the process takes too long you the connection is reset by some node that is involved in the communication.
So there are two things to do:
Inform the ISP about those problems. They probably will help you trace the exact problem and help their clients so they can use your service. For that you need to know the ISP of the users that have the "connection reset" problem. Send them to https://www.whoismyisp.org/ or similar site.
Upgrade to IPv6 as soon as possible. Your server can use both versions of the protocol at the same time.
Check the load on your server. Looks like server is closing connections because of load - exception on web-service call
I have a java client that invokes a thread to hit a servlet and retrieves last few lines from logs at the server, and show the retrieved log lines on the client. Every once in a while, the log thread times out.
Application server is Tomcat, but the error is intermittently reproducible across both Tomcat and Websphere, with client on Windows and server on Windows. With client on Windows and server on AIX, this problem has not occurred till now. I must mention that the code was stable for quite a few iterations, and suddenly started giving these problems.
What I have tried so far
The log reading client invokes the thread every 0.1 sec (used a sleep). I tried increasing the sleep time to 5 sec in the code, but it did not help.
When creating URLConnection object, I set properties like connectTimeout and readTimeout. I don't think readTimeout can be a cause, because that would have thrown a Socket exception.
3 I tried working with Tomcat configuration.
Connector port="9962" protocol="HTTP/1.1" connectionTimeout="200000" redirectPort="8445" acceptCount="30"
4 . The url connection is "disconnected" after use.
5 The stack trace seems to imply that the request never reached the application server, could this be because of some OS layer limits on connection. But in that case, there would have been an entry in the Event viewer of Windows.
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
How would you go about diagnosing this problem? The server logs don't show anything suspicious. The client and server do not have any other networking devices to the best of my knowledge so no proxy is required, and the firewall is switched off.
I have not used keep alive thus far.
It is difficult to predict what is causing this. However, your next step should be to try running a packet sniffer on the client and / or server to see if the TCP connection requests are making it to the windows machine.
If the problem occurs both with Tomcat and Websphere, that would imply that the cause is at a lower level; i.e. in the OSes TCP/IP stacks, firewall ... or in the network. (And if the server is running in a virtual, it could be a drop-out in the virtual networking.)
Iam using HTTPClient 4.0 to connect a remote server and transfer file using HTTPS.
When i tried to connect i get the exception "java.net.SocketException: Unconnected sockets not implemented".
Please look at the stack trace
java.net.SocketException: Unconnected sockets not implemented
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at java.io.IOException.<init>(IOException.java:40)
at java.net.SocketException.<init>(SocketException.java:29)
at javax.net.SocketFactory.createSocket(SocketFactory.java:2)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.HttpConnection.open(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionHTTP.ejecutarTransmisionHTTP(TransmisionHTTP.java:107)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmisionAuto(TransmisionFTPNew.java:483)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmision(TransmisionFTPNew.java:1016)
at co.com.personalsoft.ftpautomatico.ConexionThread.run(ConexionThread.java:58)
at java.lang.Thread.run(Thread.java:595)
The same error is found while using HTTP Client 3.1.
My Environment
Application Server : Websphere application server 6.1.0.23
Java : JDK 1.5.0.16
Actually a more complete answer than suppressingfire is
Add com.ibm.ws.admin.client_7.0.0.jar to java build
This solves the java.lang.NoClassDefFoundError: com.ibm.ffdc.Manager error.
Add to setup:
import java.security.Security;
...
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");
This solves the Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
When I enabled javax.net.debug, I noticed that there was a missing class com.ibm.websphere.com.ibm.websphere.ssl.protocol.SSLSocketFactory.
I was experiencing trouble in unit tests that invoke httpclient. What I ended up doing was to add this line to my TestClass.setUp()
Security.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");