I am injecting the HttpServletRequest class into a class with the #Service annotation passing the instance of the HttpServletRequest class to a utility class (AuthorizationUtils) to get the authorization header. Is there any risk in this, such as my AuthorizationUtils trying to call the method below and my service class or HttpServletRequest class already being destroyed?
request.getHeader("Authorization")
I would avoid doing that (for architectural reasons), but no, there is no risk.
What would be incorrect would be to pass the request to a separate thread (or an async method, which is executed in a separate thread). Not because the class would be "destroyed" (that doesn't exist), but because the specification says:
Each request object is valid only within the scope of a servlet’s service method. [...] Containers commonly recycle request objects in order to avoid the performance overhead of request object creation. The developer must be aware that maintaining references to request objects for which startAsync has not been called outside the scope described above is not recommended as it may have indeterminate results.
If your service is synchronous, then the service() method of the servlet hasn't returned yet when your service method is executed, so that's fine.
Related
In one of the Spring projects I am working on there is a class annotated with #Endpoint, and the methods are annotated with #PayloadRoot. It appears to me that it works in such a way that the requests are handled synchronously and next request won't be dealt with till a response to the earlier request has been returned.
How can we improve performance in a scenario that there are requests coming in from multiple clients?
thanks,
John
Each #Endpoint class are scoped as singleton and could handle requests coming from multiple clients, so each one has it's one thread.
Check Note in http://docs.spring.io/spring-ws/site/reference/html/server.html :
Endpoints, like any other Spring Bean, are scoped as a singleton by
default, i.e. one instance of the bean definition is created per
container. Being a singleton implies that more than one thread can use
it at the same time, so the endpoint has to be thread safe. If you
want to use a different scope, such as prototype, refer to the Spring
Reference documentation.
Note that all abstract base classes provided in Spring-WS are thread
safe, unless otherwise indicated in the class-level Javadoc.
I have doubt about HttpServletRequest life object. Is the request object destroyed after it got into controller?
The lifetime of an HttpServletRequest object is just that: the time of serving an HTTP Servlet request.
It may be created right before calling the servlet's doGet(), doPost() etc. methods, and may be destroyed right after that. It is only valid to use it during serving a request.
Note: However Servlet containers may reuse HttpServletRequest objects for multiple requests (and this is typically the case), but they will be "cleaned" or reset so no objects (like parameters or attributes) will leak between requests. This is simply due to performance issue: it is much faster and cheaper to reset an HttpServletRequest object than to throw away an existing one and create a new one.
In a typical Servlet container implementation if an HTTP request comes in, an HttpServletRequest is created right when the HTTP input data of the request is parsed by the Servlet container. The whole request might be lazily initialized (e.g. parameters might only be parsed and populated if they are really accessed e.g. via getParameter() method). Then this HttpServletRequest (which extends ServletRequest) is passed through the Servlet filters and then passed on to Servlet.service() which will dispatch the call to doGet(), doPost() etc based on the HTTP method (GET, POST, PUT etc.). Then the request will still be alive until the request-response pair cycles back throughout the filter chain. And then it will be destroyed or reset (before it is used for another HTTP request).
I'd like to know what the expected lifecycle behavior is for a class that responds to REST requests.
I have a class that's derived from javax.ws.rs.core.Application that identifies another class for responding to requests.
In that other class, it is annotated with #Path("foo") and methods within this class are annotated with #Path("bar"). When a request is made to foo/bar, I can see that the constructor is executed, then the PostConstruct method is properly called. After the method returns a response to the client, I can see that PreDestroy is called and then the class is squashed. On the next request, the process repeats.
Is this the correct behavior? Or is there a way that this class can remain in memory so that it doesn't need to go through the constructor and PostConstruct each time a request is made? This method relies on JAXB marshalling and various XSL transformations - I would like to cache the compiled XSLT transformation objects as well as the results of some transformations, but if the class is reinstantiated each time it is called, it makes it impossible for local caching.
This is running with Java 7, Wink, and Tomcat 7. Can someone please let me know if this is the expected behavior, or am I missing something that will just keep this class alive?
Thanks.
By JAX-RS specification, the Resources (the classes annotated with #Path) are created per request.
There are several ways to override this behavior.
The simplest way that can be used according to the JAX-RS specification, is to create a resource instance yourself (you are responsible to call the PostConstruct, not sure when and how you call to PostDestroy in this case) and return it using javax.ws.rs.core.Application.getSingletons()
Alternately, you can put #org.apache.wink.common.annotations.Scope(ScopeType.SINGLETON) annotation on your resource.
If you use Spring, Wink has a neat Spring integration module, so the Spring's lifecycle will be used. See http://incubator.apache.org/wink/1.0/html/5.5%20Spring%20Integration.html
I would like to read some parameters during servlet initializtion (in init() method), and store them among servlet context attributes (using getServletContext().setAttribute()). I would like to read these parameters later - during some request processing (using getServletContext().getAttribute()). So, the multiple threads could do this simultaneously. My question is if such an attempt is safe? Could I be sure that multi threaded calls to the getAttribute() don't mess up any internal state of the servlet context?
Please take into account that I'm not going to call the setAttribute() anywhere besides the initialization. So, only calls to the getAttribute() are going to be done from multiple threads. But depending on the internal implementation, this also could be dangerous. So, any information about Tomcat's implementation would be appreciated.
The primary implementation of ServletContext in Tomcat is the ApplicationContext class. If you look at the linked resource, you will see that the attributes are stored in a java.util.concurrent.ConcurrentHashMap instance. So, for ApplicationContext at least the getAttribute() and setAttribute() methods are thread-safe.
I have a cache of objects (not the HTTP session attributes) and I want to be able to get an object from this cache when a Hessian request comes in and have Hessian execute the call on this object instead of the servlet.
I can control the class that the request is executed on by setting the service-class and api-class init parameters on the HessianServlet. However, it is performing the instantiation of objects itself and it does not look like I can control this.
I've tried to override the execute() method of HessianServlet and calling setService() or setObject() but it does not use the object I've passed in. Instead it seems to instantiate its own.
A simple hack is create a service class that has the same interface on your object, which delegates to an instance of your object it fetches to the pool, expose this service through Hessian.