Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
see https://bugs.openjdk.org/browse/JDK-8253368
java connector use same pattern :
try { |
try { |
long maxCurrentMillis = System.currentTimeMillis() + 10; |
socket.shutdownOutput();
|
socket.setSoTimeout(3); |
InputStream is = socket.getInputStream();
|
//noinspection StatementWithEmptyBody |
while (is.read() != -1 && System.currentTimeMillis() < maxCurrentMillis) { |
// read byte |
}
|
} catch (Throwable t) { |
// eat exception |
}
|
writer.close();
|
reader.close();
|
} catch (IOException e) { |
// eat |
} finally { |
try { |
socket.close();
|
} catch (IOException e) { |
// socket closed, if any error, so not throwing error |
}
|
}
|
And bug state that:
the shutdownInput() triggered a fatal/internal_error call, which sent a fatal alert, and also invalidated the session. This caused performance hits when reconnections would cause full handshakes instead of fast resumptions.
Goal of this task is to ensure that when using SSL this case doesn't occurs to our connector (apache ends up removing those in https://github.com/apache/httpcomponents-core/commit/f7e876b)
second goal is to ensure resumption is desirable for connector (see https://bugs.openjdk.org/browse/JDK-8190697)