tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex O'Ree" <alexo...@apache.org>
Subject Re: intermittent connectivity failure under ssl
Date Mon, 05 Mar 2018 13:59:34 GMT
I may be on to something. I found at a coderanch something that was
related. I'm using a class that extends Http11NioProtocol to provide
encryption support for the keystore passwords. I was setting the xml
attribute in server.xml/Connector@protocol = the class name of the extended
class. This may be related to the problem as it looks like the protocol
attribute must be one of HTTP/1.1, etc.

Assuming this is the issue, which attribute can i used to specify my
overridden class?

On Fri, Mar 2, 2018 at 1:58 PM, Alex O'Ree <alexoree@apache.org> wrote:

> Remy, what more information would you like? Any more info on the issue
> that you are referencing?
>
> On Fri, Mar 2, 2018 at 10:56 AM, Rémy Maucherat <remm@apache.org> wrote:
>
>> On Fri, Mar 2, 2018 at 4:19 PM, Alex O'Ree <alexoree@apache.org> wrote:
>>
>> > Ran into a strange problem, not too sure what the problem is. Basically,
>> > I'm getting intermittent connectivity from a http client to tomcat but
>> only
>> > through SSL using the Http11NioProtocol. Some http requests go through,
>> > others fail with the stack trace below. Usually, restarting tomcat fixes
>> > it, but it appears to be random and unpredictable. This is a bit of a
>> major
>> > issue for me so any help is appreciated.
>> >
>> > Any pointers for how to troubleshoot this? Running tomcat 8.5.28.
>> >
>> > There's no tomcat logs to indicate that there's a problem. The
>> following is
>> > logged on the client side:
>> >
>> > Caused by: java.net.SocketException: SocketException invoking
>> > https://localhost:8443/myproject/services/Endpoint1: Unexpected end of
>> > file from server
>> >
>> > <snip>
>> >
>> > Caused by: java.net.SocketException: Unexpected end of file from server
>> >         at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.
>> > java:792)
>> >         at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
>> >         at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(
>> > HttpURLConnection.java:1536)
>> >         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(
>> > HttpURLConnection.java:1441)
>> >         at java.net.HttpURLConnection.getResponseCode(
>> > HttpURLConnection.java:480)
>> >         at sun.net.www.protocol.https.HttpsURLConnectionImpl.
>> > getResponseCode(HttpsURLConnectionImpl.java:338)
>> >         at org.apache.cxf.transport.http.URLConnectionHTTPConduit$
>> > URLConnectionWrappedOutputStream.getResponseCode(
>> > URLConnectionHTTPConduit.java:266)
>> >         at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStrea
>> m.
>> > handleResponseInternal(HTTPConduit.java:1543)
>> >         at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStrea
>> m.
>> > handleResponse(HTTPConduit.java:1513)
>> >         at org.apache.cxf.transport.http.HTTPConduit$
>> > WrappedOutputStream.close(HTTPConduit.java:1318)
>> >         ... 46 more
>> >
>>
>> It's impossible to say without more information, but this could look like
>> an issue that is fixed in the next build.
>>
>> Rémy
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message