I want to create a REST API in spring boot which can handle around 100TPS. Lets say I create a basic REST api using a sample application in spring boot. Does this automatically handles multi threading. Lets consider the code bellow.
#RequestMapping(method = RequestMethod.POST, value="findByPackageActivationId")
#ResponseBody
public JSONObject findByPackageActivationId(#RequestBody IncomingRestObject incomingRestObject) {
//My work here
}
By default Spring Boot web applications are multi-threaded and will handle multiple requests concurrently.REST controller is multithreaded as the DisptcherServlet handles multiple requests from the clients concurrently and serves using the respective controller methods.You can change any of the default thread settings as well (e.g. server.tomcat.max-threads). For more information refer here :-
https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc
REST controller is multithreaded as the DisptcherServlet handles multiple requests from the clients concurrently and serves using the respective controller method
You can scale your app as per your requirements to achive desired TPS
https://dzone.com/articles/how-to-test-if-your-multi-threaded-java-rest-servi
For every request from the client, the server will create a new thread and assign that request to newly created thread. You don't have to handle this explicitly.
Also for your requirement(100 Threads), you can configure this on the server. You can refer this link for tomcat configuration as its default server for spri.
Spring Framework provide these feature internally, these are benefits that spring provide over core servlet coding that we used to do in older days. It also provide the way to control it.
For Ex you can change limit of number of thread to create using server.tomcat.max-threads (For tomcat).
For Basic understading on multi threading with spring boot please refer https://www.e4developer.com/2018/03/30/introduction-to-concurrency-in-spring-boot/
Related
The Event Loop in Spring Webflux of having 1 core per thread handling incoming requests is supposedly one main advantage of the framework.
At the low level, other than the NIO part, how is that model any different than how tradition Servlet handles requests?
In a traditional Servlet, there's also a loop running and whenever a thread is free it'll pick up the requests.
So how is Event Loop any different? They are the same to me.
Spring WebFlux provides a higher level abstraction than Servlet spec.
Spring WebFlux requires some runtime for it to work and Servlet 3.1+ is one such runtime. Check out this part of the documentation for more details.
This is the most relevant part:
Spring WebFlux relies on Servlet 3.1 non-blocking I/O and uses the Servlet API behind a low-level adapter
How to implement a clean up method after request finish process in a spring boot application for clean data such as thread locals
I try with ServletRequestListener.requestDestroyed api, but it does not get hit after the request finish
One possible answer is that you have neglected to register the listener. The Servlet javadocs say:
In order to receive these notification events, the implementation class must be either declared in the deployment descriptor of the web application, annotated with WebListener, or registered via one of the addListener methods defined on ServletContext.
There may be other ways to implement this using Spring; e.g. using a handler intercepter; see Remove ThreadLocal object within a Spring MVC website?
If you were using plain servlets (without the Spring MVC infrastructure), another approach would be to do the cleanup in your servlet's service method or the doXxx methods. Or in a Filter in front of the servlet.
I am quite new to Spring and have a question related to Spring Service naming convention.
I have written a service, and used an annotation to define and name it.
#Service(value="CustomerService")
This service is implemented within a library that is used by a web app. Everything works fine and I can autowire my service into my client components.
Now I would also like to expose this service using http invoker. This works ok. I have define a /CustomerService http service which accesses CustomerService bean.
The issue I have is that one of my components, a client side component, that I used in my web app (CustomerDetailsValidator) can also be used in this new application.
In my CustomerDetailsValidator I have something like this:
#Autowired
#Qualifier(name="CustomerService").
But if I want to reuse my CustomerDetailsValidator and use it in my new app, this time I need to wire it to the httpservice instead.
Which means that the #Autowired and #Qualifier code is useless.
My question is what is the best practice in this case?
Should I still use #Service?
I guess I cannot use Qualifier anymore.
My feeling is that I should define everything in xml in each application context.
The web app using the library directly would just use the CustomerService bean as a singleton.
While my new client app would link the customer service id to the http service.
Is that a good approach? Do we have patterns for this?
Thanks and regards
Gilles
We currently have a level 2 RESTful web service. We are updating the service to incorporate hypermedia support. We are using Spring Data Rest on the back-end to handle the setting of the HATEOAS properties. The problem we're having is that we still need to support our legacy API consumers until the migration can be completed, meaning we still need to support responses without HAL properties like "_links" and "_embedded".
For reasons that aren't really worth explaining, we cannot address this problem with URL versioning. We need instead to be able to map requests with an Accept header of "application/json" to our old controllers, and let SDR handle any requests with "application/hal+json". In essence, we'd like to use SDR as a fallback to handle API requests that are specifically requesting HAL-formatted responses.
I came across this excerpt in the SDR documentation:
We register a custom HandlerMapping instance that responds only to the
RepositoryRestController and only if a path is meant to be handled by
Spring Data REST. In order to keep paths that are meant to be handled
by your application separate from those handled by Spring Data REST,
this custom HandlerMapping inspects the URL path and checks to see if
a Repository has been exported under that name. If it has, it allows
the request to be handled by Spring Data REST. If there is no
Repository exported under that name, it returns null, which just means
"let other HandlerMapping instances try to service this request".
The Spring Data REST HandlerMapping is configured with
order=(Ordered.LOWEST_PRECEDENCE - 100) which means it will usually be
first in line when it comes time to map a URL path and your existing
application will never get a chance to service a request that is meant
for a Repository. For example, if you have a Repository exported under
the name "person", then all requests to your application that start
with "/person" will be handled by Spring Data REST and your
application will never see that request. If your Repository is
exported under a different name, however (like "people"), then
requests to "/people" will go to Spring Data REST and requests to
"/person" will be handled by your application.
This seems to imply that what we're trying to accomplish is possible, assuming the HandlerMapping order can be configured differently. I haven't been able to make that work so far though:
Setting SDR's HandlerMapping to Ordered.HIGHEST_PRECEDENCE seems to have no effect.
Setting SDR's HandlerMapping order to Ordered.LOWEST_PRECEDENCE seemed to disable ordering altogether, and my custom controllers did field the requests, but SDR was no longer responding to any requests. application/hal+json just resulted in a 406 status.
Is there any way to configure the HandlerMappings correctly such that my custom controllers take priority and SDR fields any requests not specifically mapped to my controllers?
We have Spring MVC application. One module requires to call the Spring Controller from standalone java app.
Can I do that?
Dead easy:
new java.net.URL("http://localhost:8080/path/to/your/controller").openStream();
Just like you would do it in the browser. If you want to call the Java code directly, do not publish your controllers. Instead, extract business logic and provide it as a library.
Yes.
It's a POJO, especially if you use Spring 3.x. The newest versions don't even extend an interface or base class.
I'd call it through its http interface as it's a Spring controller. You could use a clientside http request and use the response. I'm guessing the method you wish to call does not resolve to a view, if that's the case then just use something like the RestTemplate class that comes with Spring 3.
Not sure if it would be a good idea to call it directly as Spring MVC projects are usually hidden away inside servlet wars.