On Mon, 16 Jun 2025 09:59:08 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>>> the issue here's isn't about not waiting for the tasks to complete. They in >>> fact do complete. The actual issue is that the tasks have no way to know if >>> the server side has actually done a `FileInputStream.close()` for the fixed >>> length case >> >> @jaikiran, `executor` is configured for the servers via `s1.setExecutor >> (executor)` and `s2.setExecutor (executor)` lines above. I was under the >> impression that shutting down the executor (i.e., interrupting the server >> handlers) would result in server releasing all acquired resources, including >> issuing a `FIS::close`. Was I mistaken? > >> I was under the impression that shutting down the executor (i.e., >> interrupting the server handlers) would result in server releasing all >> acquired resources, including issuing a FIS::close. > > It's not the `HttpServer` implementation which opens and closes these file > descriptors. Instead it's the (application specific) request handlers - in > this case it is the test specific `FileServerHandler` which knows which file > to open and serve and then close when done. It's done here > https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/net/httpserver/FileServerHandler.java#L121. > The `HttpServer` will not know of any resources that these application > specific handlers would have opened. Thanks, now I see. Those resource usages in `FileServerHandler` should ideally be wrapped in try-with-resources, but that is out of the scope of this work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149593103
