[HN Gopher] Show HN: Open-source non-blocking NIO Java HTTP Server
       ___________________________________________________________________
        
       Show HN: Open-source non-blocking NIO Java HTTP Server
        
       Author : mooreds
       Score  : 39 points
       Date   : 2022-10-24 16:22 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | exabrial wrote:
       | Regarding the venerable Tomcat, they [somewhat] recently added
       | support for Unix domain sockets.
       | 
       | * https://github.com/apache/tomcat/pull/402
       | 
       | * https://github.com/apache/tomcat/pull/532
       | 
       | We fronted the server with haproxy LTS. Our initial testing
       | showed roughly and order of magnitude [10x] increase in the
       | number of requests the server could handle.
       | 
       | It's not completely plug-and-play; we still had a write a custom
       | valve to set the request remote ip address and some other TCPish
       | stuff, but nevertheless the capacity far outstripped our need for
       | the technology.
        
       | taftster wrote:
       | Another person commented the same, but a "project loom" virtual
       | threads based HTTP server implementation would be very desirable
       | right now. A new NIO based server probably doesn't add a whole
       | lot of value to the ecosystem. But note, I'm not discounting the
       | effort here.
       | 
       | I do like the fact that this project attempts a no-dependency
       | implementation. That's nice. And of course, there's always room
       | for one more http server implementation, if it offers some
       | alternative to existing solutions (throughput, api, processing
       | model, etc.). But any "new" http server projects wanting to start
       | from scratch today would be wise to base its implementation on
       | virtual threads (in my opinion).
        
         | mooreds wrote:
         | Thanks for the feedback. Full disclosure, I work for the
         | company which open sourced this project.
         | 
         | I haven't been following loom closely, but it appears there are
         | still pieces being put in the Java SE for it and it hasn't been
         | fully delivered.
         | 
         | For instance, in java 19, virtual threads are still in
         | preview[0].
         | 
         | If you wanted to build a web server running on a LTS of Java
         | with loom, you'd have to wait until Sep 2023[1] (though of
         | course you could write code against versions 19+ too).
         | 
         | I think it'd be great to file a feature asking for loom
         | support[2], but do you really think loom is ready to be the
         | foundation of a prod ready web server right now?
         | 
         | Sorry if that sounds like FUD, but I truly don't know. the two
         | projects[3][4] linked in the infoq article are explicitly
         | experimental or demo apps.
         | 
         | That said, I did find this thread of projects that support loom
         | now[5].
         | 
         | 0: https://www.infoq.com/news/2022/09/java19-released/
         | 
         | 1: https://www.oracle.com/java/technologies/java-se-support-
         | roa...
         | 
         | 2: https://github.com/FusionAuth/java-http/issues
         | 
         | 3: https://github.com/rokon12/project-loom-slides-and-demo-code
         | 
         | 4: https://github.com/nipafx/loom-lab
         | 
         | 5: https://twitter.com/nipafx/status/1567448335367151616
        
       | Thaxll wrote:
       | If Netty get you that number you should spend the time
       | understanding why because your benchmark is 100% wrong.
       | 
       | It's a bit hard to beleive that one of the most used and fastest
       | Java framework is chocking with a trivial test.
        
       | kitd wrote:
       | I appreciate the simplicity of the API compared with other
       | libraries. Especially when setting up TLS. That by itself is a
       | big win IMHO.
        
       | gresrun wrote:
       | If you're only getting 500qps out of Netty something is deeply
       | wrong with your set up. I've written multiple HTTP & socket
       | servers based on Netty (albeit 6+ years ago) and they all could
       | handle 20kqps+.
        
         | tyingq wrote:
         | Probably a combination of Netty having a small default thread
         | pool size (2*cores) and the benchmark doing something blocking
         | or compute intensive. Tomcat defaults to 200 threads, which
         | would explain the difference.
         | 
         | Edit: Though the page says _" The controller does nothing
         | except return a simple 200"_.
        
         | chrisseaton wrote:
         | Yeah really doesn't add up - 2 ms to just return a code? What
         | could it possibly be doing with so much time.
        
           | tilt_error wrote:
           | The Nagle algorithm interferring with a small packet size,
           | perhaps?
           | 
           | The 2ms delay would be just about right.
        
       | samsquire wrote:
       | I am interested in the nonblocking and parallelism of modern
       | server architectures.
       | 
       | I am curious what server architecture leads to the best
       | performance. There was an interesting post the last few days
       | about epoll being broken due to thundering herd.
       | 
       | My understanding is Apache is a forking web server whereas Nginx
       | is an epoll event looped.
       | 
       | I wrote an epoll echo server that multiplexes multiple
       | connections to threads and uses a multiconsumer multiproducer
       | RingBuffer to send sockets to different threads.
       | 
       | https://GitHub.com/samsquire/epoll-server
       | 
       | My plan is to also parallelise send() and recv() on different
       | threads for sending and receiving in parallel with different
       | threads.
       | 
       | I am yet to use NIO in Java but I've heard Netty is high
       | performance.
       | 
       | I would like to use io_uring for maximum performance.
       | 
       | One of my hobbies is trying to build a multithreaded architecture
       | that can support full parallelism and scale with hardware.
       | 
       | Nodejs and python rely on process based parallelism but C, Rust,
       | Java and C# can provide real parallelism. I work on various
       | multithreaded problems on my GitHub.
       | 
       | I am yet to add network support to the algorithms in this
       | repository.
       | 
       | https://GitHub.com/samsquire/multiversion-concurrency-contro...
        
       | zokier wrote:
       | Bit awkward timing with project loom looming in the future
        
         | mooreds wrote:
         | Aren't loom and nio somewhat orthogonal?
         | 
         | Agreed that the threading parts of this project might need to
         | be looked at/reworked when loom is released.
         | 
         | More discussion here:
         | https://www.reddit.com/r/java/comments/nsb2w1/will_loom_rend...
        
           | MrBuddyCasino wrote:
           | Isn't the point of project loom that you can just use pseudo-
           | blocking IO using the traditional thread API on a fiber
           | scheduler, making NIO in application code obsolete?
        
           | NoBreakfirst wrote:
           | I haven't try loom yet but the thread api looks untouched ?
           | That was my understanding.
           | 
           | But yeah ... opening this project I was scanning for Java 19
           | / loom reference
        
           | Scarbutt wrote:
           | _Aren 't loom and nio somewhat orthogonal?_
           | 
           | No, they are virtually the same abstraction.
        
       ___________________________________________________________________
       (page generated 2022-10-24 23:01 UTC)