I have studied what exactly are Asynchronous Servlets, just tried to accomplish the same thing by writing the below code,
I know very well that i should not try to reinvent the wheel, but just have given a shot, but the code is not working as intended
actually when i am running the code, I expected the thread to sleep for 5 seconds, and then print the response, thats what my code is intended to do
but unfortunately i am getting the response immediatly, can somebody please explain me where i am going wrong?
Thanks in advance
Asynchronous processing in J2EE/JEE can be done, but not by such crude methods.
In J2EE, you needed to have such threads spawned and owned by some mechanism external to the servlet/jsp request processor code. Commonly this mechanism was set up in a servletContextListener method, although the init() method of a servlet was also popular, if less desirable.
In the latest JEE, this common need has been recognised and cleaner mechanisms have been defined. However, I'm going to have to leave you to read the JEE documentation for yourself, as I haven't had need/opportunity to dig into it myself yet. For one thing, I'd have to do version upgrades for all the servers I expected to use this new technology on.
For a second i was not sure, where i was going, thanks again for pointing me in the proper direction
it was foolish of me, thinking to accomplish the task without using the existing API
but can you please give me clarity on the sentence which you have mentioned below
Tim Holloway wrote:In J2EE, you needed to have such threads spawned and owned by some mechanism external to the servlet/jsp request processor code. Commonly this mechanism was set up in a servletContextListener method, although the init() method of a servlet was also popular, if less desirable.
I mean how can i accomplish that by using the ServletContextListener?
and also according to your quote regarding the Asynchronous Processing, i am already going through that
waiting for your kind response
- X 2
These methods don't run under a pooled thread. We can consider them to be invoked while running under a "main" thread that is active for the life of the web application, and therefore not subject to the pool thread rules.
So in in that thread, the servletContext startup method can spawn any sort of thread(s) it wants to and be assured that they will run safely undisturbed. They can even spawn child threads of their own.
A well-written web application, of course, will want to tidy up when the web application shuts down, so these threads should have mechanisms that inform them when to clean up and exit their run() methods that can be invoked from the servletContext shutdown method. Usually you'll use some sort of synchronized access to do that.
The reason why HTTP request/response code cannot spawn threads is that the HTTP request/response code that invokes the service() method in HttpServlet (and thereby the doGet, doPost and so forth) is run under a thread pulled from a pool of (supposedly) identical threads. It should process the service request as quickly as possible, then exit, which will return the thread back to the service pool. If the returned thread has resources dangling off of it - such as child threads - then the concept that all threads in the pool are identical is violated and when the thread is used again, it will be carrying leftover baggage that might interfere with its proper execution.