Bringing the OutputRecord's lock of JDK-8221882 that was left out by JDK-8240827

[Langer, Christoph]

Hi David,

yes, at the time of downporting JDK-8219991, we decided to bring only a subset of the changes of JDK-8221882 to 11u in order to avoid churn. We left out the OutputRecord modifications.

If you're in need of these changes now as you're backporting JDK-8224829, I think it's fine to bring them in. In my opinion you can either do that as a separate bug or as part of the backport of JDK-8224829 - just as you like.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Alvarez, David
> Sent: Freitag, 18. Dezember 2020 16:56
> To: jdk-updates-dev at openjdk.java.net
> Subject: Bringing the OutputRecord's lock of JDK-8221882 that was left out by
> JDK-8240827
> 
> Hi,
> 
> I'm currently working on a backport of JDK-8224829 [1]. However, back
> in the day, instead of backporting JDK-8221882 [2] completely, a
> downport of the SSLSocketImpl.java was done as part of JDK-8240827 [3].
> This mean that other changes included in JDK-8221882 did not made it to
> 11u.
> 
> For JDK-8224829, I would need the lock that was added to OutputRecord
> (as the lock call is replaced with a tryLock with timeout). During the
> RFR of JDK-8240827, a small discussion regarding the lock in
> OutputRecord [4] was started, but they ended up not being included.
> 
> I would like to bring the OutputRecord's lock changes to 11u, and once
> I have them, backport JDK-8224829. Can I get an opinion from the
> maintainers? Would it be possible to have a bug for 11u created for
> these OutputRecord's lock changes?
> 
> Thanks,
> 
> David
> --
> [1] https://bugs.openjdk.java.net/browse/JDK-8224829
> [2] https://bugs.openjdk.java.net/browse/JDK-8221882
> [3] https://bugs.openjdk.java.net/browse/JDK-8240827
> [4]
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> March/002808.html