java.net.SocketException: Unexpected end of file from server exception resolution

The company needs a similar version of the web application. When the project is deployed, the project files are the same (but the configuration is di...

The company needs a similar version of the web application. When the project is deployed, the project files are the same (but the configuration is different). When deployed to a new place, such as tomcat server, the following errors are reported:

java.net.SocketException: Unexpected end of file from server at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:806) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:665) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:803) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:665) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1230) ........ ........ at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:761)

In order to solve this problem, after several hours, it is always felt that there is a problem of mutual visits between projects. As there are 67 projects in the whole project, there are mutual visits between projects. It is indeed a problem of mutual visits to check the background log. At first, I thought it was a problem of Engineering code. Six or seven projects were deployed in three Tomcats of the same machine, and the project visits could go directly to the intranet. But throw out the above errors, all of a sudden confused, external access can be, why can't the intranet visit each other?

In order to solve this problem, we re-examined the following configuration, no mistake, and finally found that it was due to the problem of tomcat environment configuration. The former deployment was based on http protocol. Now the deployment of tomcat is based on https protocol. The http and https protocols in tomcat have different ports.

As follows, my tomcat https port is 8083

<Connector port="8083" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/u01/ssl/server.jks" keystorePass="password" truststoreFile="/u01/ssl/server.jks" truststorePass="password" />

http port is 8030

<Connector port="8030" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

Be sure to pay attention to this problem and add https support to the project's web.xml file

<security-constraint> <web-resource-collection> <web-resource-name>SSL</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

If there is a dynamic access project by getting the address in the database table, use https://ip:port This way, when I test, I report connection timeouts.

It eventually changed to https://localhost:port The way of access successfully runs the engineering code. Record the experience, facilitate farmers who encounter the same problems, and provide a solution or ideas.

23 December 2018, 01:09 | Views: 1797

Add new comment

For adding a comment, please log in
or create account

0 comments