Hacker News new | ask | show | jobs
by kirinan 4083 days ago
Tomcat/Jboss are resource hogs and tend to not do well in sandboxed environments as it takes away a lot of the configurability/tuning that they provide/need for scaling. In addition, people tend to deploy multiple applications per application server to keep resources requirements down: containizeration tends not to lend itself to multi-application stategies (in particular resource heavy applications like those that run on the JVM). This is far from something that makes java an impossibility but it changes the techniques enterprises are accustomed to. Technologies like Jetty provide a good solution to the problem, and will probably see wider adoption as containers become more prevalent.
2 comments

As someone that has deployed multiple production applications in Tomcat and Jetty, I would never choose Jetty again. The concept is good but it has severe quality issues and does not offer the same stability as Tomcat. At one point we had to fork Jetty to fix critical problems, never again.
Interesting point. I've never had an issue with Jetty, though I've never ran it at huge scale before. I've used it for internal business systems which at peak require 1000 req/s which isn't a whole lot. Do you run an wrapped tomcat to create fat jars or Tomcat as a standalone application server?
Thanks a lot for your answer. We create a separate container for each application, as it seemed like the correct approach. In our company we do have several "levels" of library (even jvm) version requirements. Containers have been very helpful to easy the pain that was managing that on the server side.
I've found that building fat JARs with all dependencies bundled solves a lot of the same dependency management issues containers can be used for. And it does it without container overhead.
That's what we do now: fat JARs, including all dependencies and use embedded app server. On top of that, we use docker containers so we can control de JVM version as well. The overhead is not that high and it gives us the benefit of knowing that the same container that the developer/jenkins tested is the one that passed QA and will run in production.
This is exactly what should be done.
How do you apply security updates to the dependencies?
To update on this since I am a Java programmer who is picking up c again after 10 years:

In modern Java world people often maven or another project tool where upgrading a library is as simple as changing the version number in a "pom" file, push and wait for Jenkins to finish build, unit and integration tests.

Not kidding here, this is one of the things I love about Java development.

This is literally every ecosystem except classical c and c++.
You generate a fresh build with the updated libraries.
Exactly. This also ties in nicely with a test-heavy build process to make sure that said security updates don't cause any regressions.

EDIT: To give you a chance to catch those regressions, at least.