[jdk11u-dev] RFR: 8229867: Re-examine synchronization usages in http and https protocol handlers

[Goetz Lindenmaier]

On Mon, 27 Mar 2023 04:44:13 GMT, PoojaDP-23 <duke at openjdk.org> wrote:

>> Hi @PoojaDP-23,
>> 
>> when looking at the scope of this backport and its successor, [JDK-8293562](https://github.com/openjdk/jdk/commit/03f25a9c6924430ec4063b801b2b6ca55b9067c9), which I've understood is what you actually want to fix, I'm a bit concerned whether this is appropriate as a backport to JDK11. After all, it completely reworks the locking in the HTTP client and we can't be sure what side effects this might cause in other productive usages. It might even unveil issues that have not been discovered in head.
>> 
>> So, could you go back and give some more explanation what kind of bug you want to fix in 11u? Maybe we can find a less intrusive fix that could also differ from OpenJDK upstream? Maybe JDK-8293562 can be adapted for 11u without this one?
>> 
>> Thanks
>> Christoph
>
> Thanks for the update  @RealCLanger  
> 
> Yes, we need to backport JDK-8293562 to jdk-11 and backporting the dependency as well. Please let us know about the less intrusive fix, we shall evaluate if this resolves the issue.
> 
> Also, could you please help us understand the following ?
> 
> 1) How this backport will be different from JDK17 as this is already backported to JDK17 and what/why are we expecting side effects in JDK11 ? 
> 
> 2) Unit test suite execution will be sufficient to confirm the adaptability of these two backports or what exact side effects to be concerned with. 
> 
> Please share your response ASAP. It will help us to decide on next steps. thx

Dear @PoojaDP-23 

Christoph already reasoned why he thinks this is not appropriate for 11: " After all, it completely reworks the locking in the HTTP client and we can't be sure what side effects this might cause in other productive usages. It might even unveil issues that have not been discovered in head."

You did not give a reason why you need these changes yet.   Please reason for this carefully. 

You ask "Please let us know about the less intrusive fix," It is up to you, the Contributor, to draft a less intrusive fix. If you can not do that yourself, you also can not judge the risk of the backport properly because you have not understood the fix.

ASAP is not a vocabulary used typically in open source projects where people work on a voluntary basis.

Please see https://wiki.openjdk.org/display/JDKUpdates/JDK11u for a description of eligible backports.

-------------

PR Comment: https://git.openjdk.org/jdk11u-dev/pull/1710#issuecomment-1484517595