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: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)