2

We most likely deploy a JVM-based Web application (e.g., Scala) on a container (e.g., TOMCAT, Jetty, etc.). Does the following points about a serverlet container goes against us to create a scalable and fault-tolerance Web application?

Single Point Of Failure: If the container fails the application fails. Also, we can't update the application while it is on the container.

Large Number of Simultaneous Connections: Based on my understanding we can't use a container to deliver the Web application to tens of thousands of users per second.

  • @gnat Checked out the question/answer suggested. I don't think they are the same question. Updating the content right now. – o-0 Feb 3 '15 at 11:57
  • Could you elaborate on your understanding of the scalability? And I'll say up front, your understanding is probably wrong (in that Java in a container is just as capable of scaling as other languages and platforms). Additionally, I am curious about what you consider the container to be and how it differs from other web platforms and their 'containers' (php running in Apache, or ruby running in Passenger or Python running in wsgi...) – user40980 Feb 8 '15 at 2:37
2

You should not use a container, but use a containerless framework such as Play instead. Regarding your points:

Single Point Of Failure: This is independent of deploying in a container or not. I you just deploy one instance of your app and it crashes, it's down. For high availability you'd use multiple running instances and load balance between them, with container or without.

Large Number of Simultaneous Connections: The Servlet API is based on a thread-per-request model, i.e. each request will take up an entire thread. This can be a newly spawned one, or more likely one taken from a thread pool. So the maximum number of simultaneous requests is determined by your container's thread pool size, or the number of JVM threads your hardware can handle well. That number is probably not as high as you'd like, as each servlet container thread takes up a lot of memory, and switching between threads is a relatively costly operation. You'll make much better use of your hardware with an asynchronous approach, where each thread handles many requests concurrently, i.e. with a framework that is not based on the Java EE Servlet API.

For more details about Play's asynchronous approach I recommend: http://www.slideshare.net/Typesafe_Inc/why-play-framework-is-fast

Maybe try out the "Reactive Scales" app to get an indication how many requests/second Play handles on your machine.

An elaborate view of why "Java Application Servers Are Dead" is given in http://www.slideshare.net/ewolff/java-application-servers-are-dead

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.