Discussion point - any features of jdk.httpserver desired? managing idle connections perhaps?

[rbygrave]

I presume that we are aware of jdk.httpserver so I am having a quick look at the features of jdk.httpserver and just opening this as a discussion point to see / confirm if there are any features in there that might be considered desirable for microhttp.

Glancing at the jdk.httpserver code and the thing that popped out was the management of idle connections. It has a background timertask to manage idle connections (plus an optional one to manage request exceeding MAX_REQ_TIME and MAX_RSP_TIME).

Are there any features in jdk.httpserver that are desired to be added to microhttp?

[ebarlas]

Thanks for mentioning the JDK HTTP Server. I've been using the equivalent in Python for years and I'm looking forward to having that feature in the JDK.

Microhttp already deals with idle connections using a socket timeout and an associated scheduled task for each connection. At one point I had an additional request timeout for each connection, but I wasn't convinced it was providing much value.

And I also considered a response timeout, but that has some caveats as well. If an application is simply slow to invoke the callback (what I would intuitively expect here), it doesn't do much good to close the connection prematurely in terms of resources. The application is still holding on to the callback and effectively keeping the connection object alive. The system network resources would be freed, but not heap objects.

Just trying to strike the right balance. I want just enough to ensure Microhttp isn't vulnerable to resource leaks, but not much more.

[rbygrave]

Just trying to strike the right balance

Yes, that's all good by me. Assuming you've had a quick look at the jdk.httpserver and seen nothing of interest there we can close this.

and I'm looking forward to having that feature in the JDK.

Er, maybe I misinterpret you there but jdk.httpserver has existed since Java 6 and with 9 became the jdk module called jdk.httpserver. So it's existed for ages, what they are doing is adding a file serving feature to it.

If you haven't looked at the source you should be able to go to the jdk.httpserver module and your IDE should have the associated source. To me it is interesting to compare the two.

[rbygrave]

As some background, I have a web routing library that abstracts over jdk httpserver, jetty, grizzly and undertow. So I'm looking at providing that abstraction over microhttp - makes it easy to build a minimal "json rest service" (K8s ready with liveness, readiness, graceful shutdown etc). The jdk httpserver is nice and light and very usable but my thought is that microhttp could be very impressive and the preferred choice. Once I get something going I could benchmark it against any of those other servers just by changing a dependency + with/without Loom (virtual threads) - ideally benchmark well against Jetty.

[rbygrave]

... but yes, feel free to close this one.

[ebarlas]

Thanks for the clarification. I thought you were referring to the JEP 408 replacement.

I haven't looked at the code, but I'll make a note to do so at some point.

Closing this out.