Not directly. What you can do though is submit the request from the browser, put some operation in a queue and return immediately with a page that will call another servlet (or the same one, either way) to poll for the status of the queued operation.
There are packages out there to do such things without you having to build the functionality, but it's not a big deal to build it either. The bottom line though is that once your servlet completes, you cannot guarantee access to the request/response because the container will do what it will do with it. That's almost certainly why, as you say yourself, sometimes you get a response and sometimes you don't. The times you do is when your process finished before the container finished with the response, so you just got lucky, timing-wise.
Just queue the operation and let the browser poll for the status. You don't have to show anything to the user that you don't want to either... Use a frameset. In the main frame where the form is submitted from, just show a Please Wait message (as returned when the request was queued). Then have a hidden frame that does the polling and updates the main frame when it's done. That way, the user will just continue to see Please Wait until your ready for them to see something different.
Remember that anything asychronous pretty much boils down to two possible approaches: callbacks and polling. You could do either (callback to an applet for instance), but polling is probably easier.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Dakota Jack wrote:
Why do you want to put the request in the queque? I do something similar in a messaging application that runs in the background. I have the message related matters bundled in an interface called Message that is passed to the multithreaded queque. Is there an advantage to passing the request to the queque instead of something engineered to handle that task? I guess I have Frank's question: why, why, why? ;-)
Jack
On Sat, 27 Nov 2004 13:28:31 +0530, Santhosh Thomas <[EMAIL PROTECTED]> wrote:
Or, are you trying to run some long-running process and think it would be better off as it's own thread? If that's the case, you probably want to look into some sort of queueing mechanism with either status polling or some sort of callback when the task is complete. Again, more details would be helpful.
No my process is not time consuming. It will finish in milliseconds and in the worst case can take a few seconds. I am not spawning a thread from each servlet request, but the request processor is another independent thread(started at web init) proecssing a queue of requests. I am only putting the request into the queue from doGet(). After putting into queue, the doGet() returns. The request processor thread then forms the response and tries to flush the output later. My experience is, sometimes I get the output in the browser, sometimes not. I thought it was a broser catching problem (I am not sure..). I cant do a polling in the servlet, bacause it will block my servlet.
Has there any way to implement asynchronous request/response using servlets?
thanks and regards Santhosh
---------------------------------------------------------------------
Couple of things...
No, I don't believe you can do anything with request/response after you exit doGet(). Well, let me amend that... you MIGHT be able to get away with it, but I wouldn't expect it to work all the time. What I mean is, once your servlet is done it's work, the container takes over again, and even if you do have a valid reference to the object, I wouldn't expect that you could make any safe assumptions about the state of that object. You might get away with it sometimes, but probably not every request.
The other point I wanted to make is that there is a pretty standard rule against spawning threads to service requests. Simply stated, you aren't supposed to do it. The container is supposed to spawn threads as appropriate to service requests, and if your doing it on your own you are more or less "competing" with the container. Bad Things (tm) tend to happen under those circumstances.
I'm not really sure what you are trying to accomplish, but I'm taking a guess that you think that by spawning the threads you will be able to handle more requests concurrently. If that's not the case, please explain you goals further.
But, assuming that is correct, I think you may have a fundamental misunderstanding at work... A servlet is supposed to be thread-safe, and the reason for that is that the container will spawn as many instances of it as needed to service requests (to whatever configured limits there are of course). In other words, every request essentially has it's own thread executing your servlet, hence the need for it to be thread-safe.
In other words, you spwaning threads is superfluous because the container is already doing essentially what your trying to do on your own. So, just make sure your code is thread-safe, and your fine.
Or, are you trying to run some long-running process and think it would be better off as it's own thread? If that's the case, you probably want to look into some sort of queueing mechanism with either status polling or some sort of callback when the task is complete. Again, more details would be helpful.
As I said, I'm making assumptions here, so I could be completely wrong!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Santhosh Thomas wrote:
Hi
I know this is a basic question. I am passing the request and response object to another thread from the doGet() and after that the Get method returns. So that the processing is done in the thread and response to client will be flushed later. But by that time the servlet method would have returned. My question is, is it possible to flush the output to the client even after the servlet method returned (or response is commited) by tomcat. I am not talking about any server push but it is a simple http question.
If http does not support this, how can I implement this? can i do this by extending the generic servlet instead of HttpServlet?
Any help is greatly appreciated
thanks and regards Boolee
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
