I am using pieces of the Spring MVC framework; in particular, I am making use of the #Controller, #RequestMapping and #ResponseBody annotations, in conjunction with a webstatsHttpMessageConverter hooked up to an OXM jaxb2 marshaller bean. My controller methods use the #RequestParam annotations to parse some GET parameters, query a service that uses a JPA EntityManager behind the scenes, and returns a JAXB object that is converted to its XML representation by the HttpMessageConverter.
I pared this scenario down to a very simple test case to try and determine the location of an execution delay that I have noticed; Example controller method:
#RequestMapping("/my_service__method_endpoint")
#ResponseBody
public Jaxb2CompiledClass getSomeData(#RequestParam String param1,
#RequestParam Date start, #RequestParam Date end) {
log.debug("Entering getSomeData");
Thread.sleep(5000);
log.debug("Finished waiting, leaving getSomeData);
return new Jaxb2CompiledClass();
}
This scenario works fine, and returns the appropriate data in the appropriate format. However, while load testing this configuration, I've run into a problem - each of my controller methods annotated with #RequestMapping will not run concurrently; if I spawn multiple HTTP requests to the service endpoint, each method call will finish before the next HTTP request is processed. In my actual code, I am using service objects to pull results via JPA and transform those results into an object of the appropriate Jaxb2 class. My understanding is that this controller should be able to run these methods concurrently, one for each HTTP request invoking the /my_service__method_endpoint. Is there some fundamental concept I am missing out on here? The log output from the code above shows that each call to getSomeData is waiting for the previous invocation to complete running before kicking off. This is obviously highly undesirable in a high-volume environment.
Skaffman's response is correct - everything is working fine concurrently, but because I was too lazy to use a real load testing tool, my browser was throttling the requests before they were sent.
Related
I am too much confused the difference between #EnableAsync and AbstractDispatcherServletInitializer#isAsyncSupported().
As per this link,
The isAsyncSupported protected method of AbstractDispatcherServletInitializer provides a single place to enable async support on the DispatcherServlet and all filters mapped to it. By default this flag is set to true
Based on my knowledge #EnableAsync is to enable scan #Async annotations and provide multi-threading support. But still I am unable to understand when to use AbstractDispatcherServletInitializer#isAsyncSupported()
There is a big difference between the two, #EnableAsync with #Async are not concerned with spring-web-mvc, they allow the execution of a method asynchronously using a TaskExecutor. For example, if you had a clean up service that deletes all logs in a server, you can allow its doCleanUp method to run asynchronously without having to write the scheduling code, spring will take care of it for you:
public class CleanUpService {
#Async
public void doCleanUp() {
// This code will be executed using a different thread than the calling thread by a TaskExecuter
}
}
As you can see this is not related to web development in particular. Also note that this method returns void, but if you wanted it to return a result, for instance CleanupStatistics, you can't just write the method like this
#Async
public CleanupStatistics doCleanUp() {
// This code will be executed using a different thread than the calling thread by a TaskExecuter
return new CleanupStatistics("someinformation");
}
You are required to return either void or a Future. A Future represents the result of an asynchronous computation that you can use to obtain the result of the computation when it becomes available. We will get back to Future and see how it can be used in controller methods while isAsyncSupported is true.
isAsyncSupported is a totally different story, this flag enables Servlet 3.0 asynchronous request processing, prior to Servlet 3.0 a servlet container (Tomcat for instance) would have a thread pool that handles the processing of Http requests, each thread would handle the request till the processing is complete, even if the thread had to stay idle, for example, to wait for a database query to finish or for an API call result to come back. This affects the scalability of the servlet container. In Servlet 3.0 requests can be handled asynchronously, the container thread will call your handler method, in its turn the handler method can schedule its work to be done asynchronously and return immediately, freeing the container thread to process other requests, after the result is available any container thread can resume the processing of the request. From the prospective of the client, nothing has changed, the client, all that time, is still waiting for the result to come back, but from the perspective of the server, the container threads are better utilised.
In spring-mvc you can trigger asynchronous request processing for a controller method by returning certain java types, for example
DeferredResult
Callable
ListenableFuture
CompletionStage
CompletableFuture
Reactive types
and streaming types
If you wanted to use #Async with isAsyncSupported you could write a controller method that calls a method annotated with #Async and returns ListenableFuture.
You can learn more about task execution and scheduling here. And more about Servlet 3.0 asynch here.
If we want to experience benefits provided by Spring MVC and don't want to manually register DispatcherServlet it'll be better to use: AbstractDispatcherServletInitializer. It adds two abstract methods: createServletApplicationContext() and getServletMappings().
First method returns WebApplicationContext that will be passed to DispatcherServlet, which will be automatically added into container ServletContext. This context will be established as a child of the context returned by createRootApplicationContext() method. Second method -returns mappings that are used during servlet registration.
The #EnableAsync annotation switches on Spring’s ability to run #Async methods in a background thread pool. For Enabling asynchronous processing with Java configuration got by simply adding the #EnableAsync to a configuration class.
#EnableAsync
#Configuration
public class SpringAsyncConfigurer implements AsyncConfigurer {...}
#Async is applicable only to the public methods.
Calling the #Async method within the same class woould not work.
This is a more general Spring question that isn't necessarily a Spring Social Facebook issue; however, I'm asking the question here because it is not clear to me how Spring is managing the Facebook reference that is passed into the controller constructor.
I'm running this in a Spring boot app, version 1.5.3.RELEASE.
I've googled around and have read many things about how scoped-proxies work and whether the Controller is a singleton and such; but something is still not clear to me with this particular use case. My concern is over whether or not two or more simultaneous request will cause one reference to interfere with the other. It seems to me that there will be a conflict regardless of the scoped-proxy solution. To address this concern, I injected a Facebook and ConnectionRepository object into the controller constructor wrapped in a Provider class.
#Inject
public CopyGroupController(
Provider<Facebook> facebook,
Provider<ConnectionRepository> connectionRepository) {
It appears to have injected meaningful data; but when attempting to run this code:
#PostConstruct
public void init() {
ConnectionRepository repo = connectionRepository.get();
this.userManager.createOrGetUser(
repo.findPrimaryConnection(Facebook.class));
}
This failure occurs:
java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
This creates more uncertainty because I thought the FacebookTemplate was being managed as a request or session scoped bean and that it would Inject as a Provider so the object would reside on ThreadLocale; so two or more concurrent requests will not conflict. Passing a request scoped bean in a controller singleton constructor doesn't make any sense to me either. So I'm puzzled as to why a user specific reference would even be passed into a constructor that should only be called once.
I've tried setting breakpoints in the constructor to verify whether or not there is a conflict; but The same error as above would occur. Could someone please explain to me whether or not this is an issue and if so; how is the best, most modern way to resolve it.
Any assistance would be greatly appreciated.
Thank you in advance.
You have to register a RequestContextListener
Here you can find the problem detail
And here you can get how to add in using spring boot
I'm way new to Spring.
I am looking to verify the following understanding of SpringMVC lifecycle-- to put things into places in the overall view:
The entire process is request-driven.
There is a Front Controller pattern and the Front Controller in Spring MVC is DispatcherServlet.
Upon every incoming request from the user, Spring manages the
entire life cycle as described in here.
In the overall view, DispatcherServlet dispatches the request to a controller for a service at the back-end.
Once this is done, it hands it in to the View component of MVC for its view to be prepared in response to the user.
In more detail,
DispatcherServlet uses Handlers to decide "which controller" to serve that request.
The controllers are/should be "light-weighted"-- should be decoupled from
the service processes at back end as a good design practice-- they hold references to the service(s) and invoke the right one(s).
Their "mission" is to control the service process(es) for building the model and handing
it back to the dispatcher for the next step.
The View component in itself has 2 parts: first the ViewResolver picks the right type of look for View to put the model into the final format for the user.
From the developer's angle-- the DispatcherServlet is a behind-the-scenes thing.
All i do is to define, and configure it, if necessary, in web.xml.
As the developer, I instantiate an ApplicationContext (there are many ApplicationContext types-- i pick one depending on what i need, typically the
WebApplicationContext(?) ). AplicationContext is the factory that creates all the servlets/beans including
the DispatcherServlet, using their descriptions in the .xml files. The DispatcherServlet then runs behind the scenes and manages the
entire process-- goes&gets the controllers, using the annotations or the their .xml descriptions,
views, handlers, validators etc.
I am wondering whether this description is holds-- valid&complete, and whether there are big missing pieces in it.
Thanks in advance.
Let's go into detail step by step
DispatcherServlet uses Handlers to decide "which controller" to serve
that request
The DispatcherServlet maintains an ordered List of HandlerMapping beans (which it loaded from the WebApplicationContext). A HandlerMapping is
Interface to be implemented by objects that define a mapping between
requests and handler objects.
When the DispatcherServlet receives a request, it iterates over this list until it finds a matching handler object for the request in question. For simplicity, let's consider only RequestMappingHandlerMapping.
A bean of this type stores a mapping of #RequestMapping annotated methods (the actual Method object retrieved with reflection) stored as a HandlerMethod instances and wrapped in RequestMappingInfo objects that hold mapping data for matching the request, ie. URL, headers, and request parameters.
The DispatcherServlet retrieves the best matching HandlerMethod from these and any corresponding HandlerInterceptor instances which you may have registered. It retrieves these as a HandlerExecutionChain object. It will first apply any pre-handling by HandlerInterceptors. It will then try to invoke your HandlerMethod. This will typically (but not always) be a #RequestMapping annotated method inside a #Controller annotated class. This produces what Spring calls a dispatch result. The DispatcherServlet then applies post-handling by the HandlerInterceptors. It finally processes the dispatch result depending on what it is. You can see the supported return types for an idea of what that can be.
The controllers are/should be "light-weighted"-- should be decoupled
from the service processes at back end as a good design practice--
they hold references to the service(s) and invoke the right one(s).
Their "mission" is to control the service process(es) for building the
model and handing it back to the dispatcher for the next step.
In an MVC application, the controller controls operations by making changes to the model. You can do this directly in your controller or you can decouple it by implementing and providing service and business classes for that purpose. The controller depends on these, but not the other way around. Check out multilayered architectures.
The controller then builds the model (Model) which the DispatcherServlet possibly makes available to the view. I say possibly because the controller can produce a response directly without any view (think jsp) involved.
The View component in itself has 2 parts: first the ViewResolver picks
the right type of look for View to put the model into the final format
for the user.
In the typical case where the Controller handler method would return a Model, View, ModelAndView, String (and some others) object, then a ViewResolver would handle finding the correct View. The DispatcherServlet then tries to render that view by first merging the model as you said. This usually means taking all Model attributes and putting them into the HttpServletRequest attributes. The rendering step can involve rendering a jsp, generating XML, or anything at all really.
From the developer's angle-- the DispatcherServlet is a
behind-the-scenes thing. All i do is to define, and configure it, if
necessary, in web.xml. As the developer, I instantiate an
ApplicationContext (there are many ApplicationContext types-- i pick
one depending on what i need, typically the WebApplicationContext(?)
).
You don't actually need to instantiate it. The DispatcherServlet will do that itself (or use the ContextLoaderListener's) when the Servlet container calls init() on it. It will generate its own WebApplicationContext. What you can do is decide which subclass of WebApplicationContext to use. This is an important choice if you want to load your context from XML or from a Java configuration. You can do this by providing an <init-param>.
AplicationContext is the factory that creates all the servlets/beans
including the DispatcherServlet, using their descriptions in the .xml
files. The DispatcherServlet then runs behind the scenes and manages
the entire process-- goes&gets the controllers, using the annotations
or the their .xml descriptions, views, handlers, validators etc.
The ApplicationContext is also known as the Inversion of Control Container. It does not include the DispatcherServlet. The DispatcherServlet is managed by the Servlet container and not by Spring. However, it does primarily take its configuration from Spring's ApplicationContext (WebApplicationContext). It registers a number of special beans it finds in the context. You can declare these yourself or let Spring do it for you with this little bit of XML
<mvc:annotation-driven>
This will (mostly) take care of doing what you describe, ie. registering handlers, validators, views, etc.
I am wondering whether this description is holds-- valid&complete, and
whether there are big missing pieces in it.
Don't forget that a Spring MVC web application is a Servlet web application. The lifecycle of the application is therefore tied to the Servlet container.
There is no good answer to your question. "Sure" is as close as I can get.
You can configure spring using xml files or annotations or a combination of both.
You don't need to write servlets with Spring MVC, but you can if you want. Mostly you can (maybe should) create controller classes (either by extending a Spring controller class or marking a class with the #Controller annotation).
The "mission" of the controller is to perform necessary processing of requests. They do not just "control service processes"
There is no "hand it back" to the dispatcher.
The DispatchServlet must be configured in the web.xml file,
this is never optional.
You can (maybe should) have a layer between your controller classes and any web services that you will call from the controller classes.
You can have multiple applicationContexts or use a single applicationContext.
As often as not,
the View is a JSP file.
The Controller should add DTOs (data transfer objects) that are used by the view to display non-static information.
EDIT: I removed the mention of VO objects, I (like many, it seems) incorrectly conflated DTO and VO patterns.
There is no "behind the scenes".
The DispatcherServlet receives a request and passes it to the appropriate controller for processing.
Read section 17 of the Spring Framework Reference
I need to add some audit logs to some business methods that are not in the web tier. One of the requirements are to store in this audit logs the user that executed the business method and the IP of the remote terminal. I decided to use AspectJ to Audit all this methods to avoid contaminating them with no bussiness code. (Note: I'm not using Spring, this is an old Struts 1 webapp)
public void myMethod(Object param, HttpRequest request**){
//Bussiness code that never use request param
}
#After("bla bla matches myMethod")
public void myAdvice(JoinPoint jp){
Object request = (HttpServletRequest)jp.getArgs()[1];
//bla bla using the request to get user and IP
}
So my question is, does anyone have any suggestion to obtain in a better or elegant way the Servlet Request in the Advice? In fact, myMethod does not contain Audit code (that is really good) but now have a second parammeter that is not used directly by the method and can become confusing to other developers. Please do not recomend me to advice the Servlet instead the business method.
Logging the IP from myMethod already ties the method to the web tier (or at least a tier with a meaningful IP address). An HttpServletRequest isn't appropriate, obviously, but an implementation providing "useful" information about the context of the call would be.
If the goal is to remove any extra parameter to myMethod, my first thought would be to create a RequestProcessor that stores the "useful" info in a ThreadLocal, which would be used by the logging aspect.
I am working on a mixed situation where i am using Servlets & Struts2.
I am calling a HTTPServlet and where i am processing on data.
Then I need to make a call to struts API to insert data in DB.
In that i am using HTTPSession also.
So I am calling
ServletActionContext.getRequest()
To get HttpRequest and then session in that struts action class.
Struts Action class is getting called by Servlet.
But
ServletActionContext.getRequest()
always returns NULL.
Is it because that it is not getting called by web.
First, ServletActionContext and ActionContext both use a ThreadLocal to store per-request objects (such as the request and response). This is handled by Struts2. If you attempt to call those from a Servlet, they'll return null, since the request was routed to your servlet, not to Struts2 (and thus Struts2 did not create an action context for the request).
With that said, Struts2 is a higher level abstraction over the Servlet API. The fact that you are invoking a Struts2 action from within a servlet sounds really wrong.
If you need to perform some common process in both a servlet and an action, then create a separate class to handle the process (i.e., inserting data in a database) and then call that class from both your servlet and your action.
If that isn't what you're trying to do, then please provide more details, along with an example of your servlet and action code.