As I understand - there is an opportunity to consume fewer of RAM and CPU.
As I know Servlet 3.1 already has been using NIO too. Are there any advantages in speed and/or loading?
This is a rather broad topic - but let's clear things up first.
Spring MVC is a web framework based on the Servlet API; such apps can be deployed on Servlet containers (like Jetty, Tomcat, Undertow).
Spring WebFlux is a reactive web framework based on a reactive HTTP layer; such apps can be deployed on Netty or Undertow (with native adapters) or Jetty/Tomcat/any Servlet 3.1 container (thanks to a Servlet 3.1 adapter).
Spring Boot applications can use Spring MVC or Spring WebFlux
Spring Framework 5.0 provides an FAQ about that with several useful resources. In short, this approach can be beneficial for efficiency and scalability for workloads dealing with lots of latency and concurrency.
Indeed, Servlet 3.1 async I/O does address those issues as well, but using that API requires to depart from using the other bits of the Servlet API which are blocking. This is why Spring WebFlux doesn't expose the Servlet API in its programming model but leverages a Servlet adapter.
Related
I created a Spring boot 2.0.0.M7 project with the webflux starter because I want to use all the asynchronous and the non-blocking capabilities.
I added the server.servlet.context-path but it does not work if I don't add the web starter as well.
If I add both starters can I have issues with the non-blocking functionality?
I executed some stress tests with Gatling and I have received the same scores removing the web starter or adding it.
Any help with this?
If you add both spring-boot-starter-web and spring-boot-starter-webflux to your application, Spring Boot will configure it as a Spring MVC app.
This is intentional as many Spring MVC will get the webflux dependency to leverage the new WebClient in their MVC apps. Also, as of Spring Framework 5, Spring MVC knows how to handle a few cases with Flux at the controller level.
You can always force your choice like this:
SpringApplication app = new SpringApplication(MyApplication.class);
app.setWebApplicationType(WebApplicationType.REACTIVE);
app.run(...);
In your case, this is not about forcing a choice but rather using something that's not supported in WebFlux.
The server.servlet.context-path configuration property is Servlet-specific, so it won't work with WebFlux. Currently Spring Boot does not support war deployment nor multiple web contexts for WebFlux applications. So there's no point in offering such a property.
The runtime model difference between "Servlet-based" and Reactive runtime with Spring can be quite subtle, and I encourage you to watch a talk that describes those choices. The short answer is: if you're using Spring MVC with async types (DeferredResult, Flux or SseEmitter) things will be async but reading and writing will still be blocking.
Properly benchmarking that is quite hard, but the results you're seeing are somehow expected. Running locally server+client, no latency involved, looking at raw throughput - all of those constraints should not be in favour of the reactive model which has a concurrency cost. If anything, this benchmark shows that the reactive stack is quite optimized already, even for non-ideal use cases!
I was trying to configure Spring WebFlux with JSP. I don't see any View class for supporting JSTL views in Spring WebFlux.
Does this mean that we can't develop a JSP application using Spring WebFlux?
Thanks, AJ
WebFlux is not tied to the Servlet specification so JSP support cannot be consistently implemented across deployment options.
After some investigations, I'm wondering about the benefits to use Spring Boot for client side web single page web applications foreseen with angularJS2 and Bootstrap4 ?
We will have to manage the navigation from 3 to 6 SPA and the security (openAM).
The use of Spring Boot for the backend that will embbed REST, activiti, JPA and our business logic seem very valuable.
Any recommandations about such achitecture ?
I know Glassfish uses a component called Grizzly but I am unsure of to exactly what role Grizzly performs. I have read that it is a 'front-end' for Glassfish. Is this correct? What exactly does Grizzly do, say when a HTTP request comes in or a response is being send back, does it pass through Grizzly first? And if so, for what reason?
Grizzly does all of the heavy NIO lifting on behalf of one or more of the different containers within GlassFish. It's much like the connector functionality of Tomcat. The Connectors do the network operations on behalf of the core web container.
In the case of HTTP, Grizzly is responsible for parsing and serializing HTTP request/responses. It also provides the infrastructure to allow Servlet Async support to function. In the case of EE7, Grizzly also provides the functionality necessary to support non-blocking I/O within Servlets.
Right from the project home page:
The Grizzly NIO and Web framework has been designed to help developers
to take advantage of the Java™ NIO API. Grizzly's goal is to help
developers to build scalable and robust servers using NIO and we are
also offering extended framework components: Web Framework (HTTP/S),
Bayeux Protocol, Servlet, HttpService OSGi and Comet.
A Users Guide is available along with code examples which demonstrate its various usages.
Please see the Grizzly project on Java.net for more details, and how to participate.
My friend asked to explain me what's the difference between Spring, axis2 and Jersey. Here I listed down a few differences that I'm aware of. Please comment/respond if you know more differences
Spring webservices:
A java web application with a servlet configured in
web.xml(org.springframework.ws.transport.http.MessageDispatcherServlet).
You can use spring annotated POJOs for creating web services
Supports both RESTful and SOAP based web services.
Since it’s a web application you can use http authentication mechanisms
for enabling security
Axis2:
The webservice application is a .aar file that will be deployed in
axis2.war
Use AXIOM for using non-primitive type arguments to web service calls
You can use JSR181 annotations to create webservices
You can use spring-dependency injection using axis2 extensions.
Supports both RESTful and SOAP based web services.
I guess you have to use ws-security implementation for
providing security
to your web services>
They claim hot deployment of webservices works but I haven’t seen
it working.
Jersey:
A regular web application with a servlet configured in web.xml.
Write custom message readers/writers for using
non-primitive type arguments to web
service calls
Since it’s a web application you can use http authentication mechanisms
for enabling security
Supports only RESTful implementation of web services
I have seen hot deployment working may be because it’s a web application
and the container can do hot
deployment
I'm not familiar with Jersey and Axis, but I can tell you something about Spring-WS.
You cannot use Spring-WS for restful webservices. Spring-WS is intended to be used for contract first webservices. You can however use the features of Spring 3.x and Spring-MVC for REST services.
As for authorization, you can easily wire in any sort of security (with Spring-Security for instance).
I'm a big fan of the 'automatic' (de) marshalling features of Spring-WS. Just annotate your methods with the correct types and it'll know what to do.