enola-dev / enola

Enola 🕵🏾‍♀️ Holmes was an SRE.
https://docs.enola.dev/
Apache License 2.0
18 stars 7 forks source link

Web Server is broken, due to TLC, and cannot be fixed, due to JDK hard-coding new Thread(null, dispatcher, "HTTP-Dispatcher", 0, false) #849

Closed vorburger closed 2 months ago

vorburger commented 2 months ago

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

java.lang.IllegalStateException: Missing TLC.open() in call chain, can't get: interface dev.enola.common.io.iri.namespace.NamespaceConverter
    at dev.enola.common.context.TLC.context(TLC.java:89)
    at dev.enola.common.context.TLC.get(TLC.java:77)
    at dev.enola.common.io.iri.namespace.NamespaceConverter$1.toCURIE(NamespaceConverter.java:42)
    at dev.enola.thing.metadata.ThingMetadataProvider.get(ThingMetadataProvider.java:89)
    at dev.enola.thing.metadata.ThingMetadataProvider.get(ThingMetadataProvider.java:71)
    at dev.enola.web.ThingUI.link(ThingUI.java:101)
    at dev.enola.web.ThingUI.table(ThingUI.java:80)
    at dev.enola.web.ThingUI.html(ThingUI.java:51)
    at dev.enola.web.UI.getEntityHTML(UI.java:106)
    at dev.enola.web.UI.getHTML(UI.java:94)
    at dev.enola.web.UI.get(UI.java:82)
    at dev.enola.web.SunServer$Wrapper.handle(SunServer.java:92)
    at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
    at jdk.httpserver/sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:82)
    at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:101)
    at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:871)
    at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
    at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:847)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)

Steps to Reproduce the Problem

  1. ./enola -vvvvvv server --model docs/use/library/model.yaml --httpPort=8080
  2. Open http://[::]:8080/ui/enola:/
  3. 💥
vorburger commented 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.

vorburger commented 2 months ago

(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.

vorburger commented 2 months ago

A completely different take on this could be to let TLC have a static "escape hatch"... ugly! But perhaps OK short-term? ⏲️

vorburger commented 2 months ago

(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