[8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close

[Volker Simonis]

On Tue, Jan 12, 2021 at 11:30 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 1/11/21 11:27 AM, Volker Simonis wrote:
> > Using Andrew H's proposal would certainly work as well, but from my
> > point of view it would be a bigger difference compared to the original
> > change so I'd vote for keeping David's version.
>
> It would, but the original code was obscure and misleading, and now we
> have code which is both misleading and suppresses a warning.
>

Not sure what you are meaning by "obscure and misleading". I find the
original code is concise and clear. It tries its best to consume the
input and close the socket (by calling "appInput.deplete()"), but in
any case, even if that fails, it will close 'conContext.inputRecord':

try (conContext.inputRecord) {
    // Try the best to use up the input records and close the
    // socket gracefully, without impact the performance too
    // much.
    appInput.deplete();
}

Notice that it is perfectly fine to put an autoclosable resources in
the try clause, even if that resource is not used within the try block
itself. After all, that's the reason why Java 9 simplified this
pattern by extending "try-with resources" to also accept already
existing resources as final or "effectively final" variables in the
try statement [1]. Nothing obscure at all.

In 8 however, we have to declare a new variable for the resource in
the try clause, because the Java 9 simplification isn't available. If
we were to write new code for jdk8 I could agree with you to use the
older, more traditional pattern. But we're reviewing a downport here
and for downports we have other priorities:
 - keep modifications of a change to a minimum
 - try to not impact future downports

As David mentioned, more backports in this area will follow that's why
I think that the code version he presented is the best compromise.

Best regards,
Volker

[1] https://docs.oracle.com/en/java/javase/15/language/java-language-changes.html#GUID-A920DB06-0FD1-4F9C-8A9A-15FC979D5DA3

> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>