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 > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
