On Mon, 22 Aug 2022 14:27:28 GMT, Daniel Fuchs <[email protected]> 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? > > Also I wonder if having 150 `@run` lines will scale. It might be better to > split this one big tests into several smaller one. @dfuch @Michael-Mc-Mahon : could you pls check latest changeset once ? ------------- PR: https://git.openjdk.org/jdk/pull/9958
