Santhosh Thomas 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!
Why can't you just perform your work? The request processor already
has your request at the time of doGet. If you are not using
multi-threading to perform some special type of task then you should
have no problem. It sounds like you haven't used servlets and jsp's
very much because if you are simply building the return to a get request
you just perform your work from your servlet method doGet or doPost and
that is really all there is to it. It shouldn't be any more complicated
than that other than maybe something like...if variable this then do
this...hand off to another class to process and add to the request or
you use another framework that handles passing the request to the
correct method depending on some form variable or something like that.
That's it.....you shouldn't be appending to the request queue yourself
as that is already done for you by tomcat. Standard jsp/servlet
container operation.
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]