Closed vorburger closed 2 months ago
I've debugged this, and fixed as much as I could with in #848 ... but, as detailed there, I "cannot" fix this, with code as-is:
Because of this! That "hard-coded" new Thread(null, dispatcher, "HTTP-Dispatcher", 0, false)
in the (package private) sun.net.httpserver.ServerImpl
, which is used by the (public) com.sun.net.httpserver.HttpServer
, which ignores (!) its setExecutor()
(for the HTTP-Dispatcher
thread, uses it only for something else) makes it basically impossibly to use that for anything with fancy ThreadLocal
fun?
I think I probably have only 2 choice here:
(a) ask some friends how one reports an issue about this on bugs.openjdk.org
, and then wait a few years... ⏳
(b) ditch the use of com.sun.net.httpserver.HttpServer
and switch to good ol' Jetty, or whatever else is fancy nowadays.
(b) ditch the use of com.sun.net.httpserver.HttpServer and switch to good ol' Jetty, or whatever else is fancy nowadays.
Actually, because of the existing gRPC dependency, which anyway pulls Netty, using it as an HTTP Server is probably the way to go, and would avoid pulling in more dependencies into this project. According to Baeldung, and a netty/example
this seems quite feasible, actually.
A completely different take on this could be to let TLC
have a static
"escape hatch"... ugly! But perhaps OK short-term? ⏲️
(a) ask some friends how one reports an issue about this on bugs.openjdk.org, and then wait a few years... ⏳
==> https://github.com/vorburger/vorburger.ch-Notes/blob/develop/java/openjdk-jira.md
Expected VS Actual Behavior
https://docs.enola.dev/use/server/ should work, and used to, but is broken since I had introduced TLC & Co.
Behavior
Steps to Reproduce the Problem
./enola -vvvvvv server --model docs/use/library/model.yaml --httpPort=8080