RFR: 8291226: Create Test Cases to cover scenarios for JDK-8278067

[Daniel Fuchs]

On Mon, 22 Aug 2022 08:26:19 GMT, Ramesh Bhagavatam Gangadhar <rgangadhar at openjdk.org> wrote:

> There are total 160 scenarios written with combination of client properties (Client Scenarios) and Server Response (Server Scenarios).
> 
> In tabular format, Client and Server scenarios along with expected output are documented here:[Permalink](https://bugs.openjdk.org/browse/JDK-8291226?focusedCommentId=14519074&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14519074)
> 
> This Program Should be run mandatorily in othervm mode itself since it has system property changes so can't be clubbed with other scenarios. so each scenario should be run in individual JVM.
> 
> For each and every scenario, ServerSocket is created and waits for clients to connect to it.
> isProxySet and serverReady are shared variables between server thread and client thread(main) and it should be set and reset to false for each and every scenario.
> 
> isProxySet and serverReady variables should be set by server thread before proceeding to client thread(main).
> 
> if isProxySet variable is set to true then client set the proxy value to url.openConnection(Proxy)
> <SNIPPET>
> if (isProxySet) { 
>          httpUrlConnection = (sun.net.www.protocol.http.HttpURLConnection) url .openConnection(new Proxy(Type.HTTP, new InetSocketAddress("localhost", SERVER_PORT))); } 
> else { 
>         httpUrlConnection = (sun.net.www.protocol.http.HttpURLConnection) url.openConnection(); 
> }
> </SNIPPET>
> 
> Program tries to fetch the Value of <Key, Value> Pairs of HashMap KeepAliveCache where Key is KeepAliveKey and Value is ClientVector KeepAliveTimeout is stored in Value ClientVector of HashMap KeepAliveCache.
> 
> if connection is cached then KeepAliveTimeout is stored in ClientVector. KeepAliveTimeout stored in Value(ClientVector) of HashMap KeepAliveCache is compared with Expected Value.
> 
> if connection is not cached then connection is terminated immediately.

Hi Ramesh, thanks for taking this one on. Would it be possible to first improve formatting a bit more, to make this easier to review? For instance - indentation in java code overall the whole oprnjdk code base is 4 spaces, not 2. Also it might be more concise to use List & loops to construct the various arrays, rather than copy/pasting the same line over and over (more specifically  things line the `serverScenarios` and `clientScenarios` arrays look like they could be initialized with one or two imbricated loops). This might also give you the opportunity to add a bit more comments to explain what each loop/line represents.

I also wonder about representing things as strings that get parsed and split later on. Wouldn't using structure records make it easier to understand?

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

PR: https://git.openjdk.org/jdk/pull/9958