On 4/3/06, Tp <[EMAIL PROTECTED]> wrote: > > The hype friendly "continuation" name has no business being associated > > with this particular feature, since the said feature is not > > continuations (which is a fancy - and IMO forward thinking and > > actually useful - programming model for implementing the often seen > > multiple HTML form "wizard" style process - and of course, which is > > going to use one HTTP request per form, as usual), and is also quite > > useless. > > What do you mean exactly by this? I guess I'm not familiar with the the > topic, maybe you can elaborate a little more on this or point me to > another thread about this topic.
There's no topic here, obviously, as Tomcat did not introduce the term "continuation". As I said, this was introduced to qualify a new programming model for wizard style processes that are often seen in web applications (registration, checkout, etc). You definitely need to think about this topic more, as the thread handling is very important for your application. > > If all you need is to reinvoke the service method once there's more > > input data available, you can just as easily use multiple small > > requests (over a kept alive connection), which is equally cheap in > > terms of processing and allows not breaking the HTTP and Servlet API > > designs. > > > > Well, first I hoped, that it is possible to leave the doGet() and > doPost() method without the HTTP connection being closed. If that would > be possible, then I could keep the HttpResponse and write to it, > whenever there is new data available. The HTTP connection is kept alive during a predefined time (the socket timeout) between requests. You then need to use a Tomcat connector that doesn't use a thread to handle each connection during keepalives (such as the HTTP APR connector). This will mean all your clients will rely on frequent polling to get the new posts of you chat room, which is going to cause a fairly large load on your server. > That is actually the real challenge and that's what my question is about > partly. However, once the methods finish, the http connections get > closed and I there is no way of preventing this. So, I have to keep the > thread busy, which handles the doGet() or doPost() method in order for > the connecton to stay alive. I don't understand why the connections will be closed (unless, say, the client is asking for the connection to be closed after the request), since it is not the default HTTP/1.1 behavior. You should investigate that. > This is not the real problem. You can use Object.wait() and > Object.notifyAll() to signal, when new data is available and then sent > it over the HTTP conneciton, if you can't multiplex. If there would be a > single thread I would just run through a loop and always dispatch new > messages, if there are any in the queue. Yes, but you need the 5000 or so threads to do this, and there's no workaround. So it is the real problem since it forces you to use polling. -- xxxxxxxxxxxxxxxxxxxxxxxxx Rémy Maucherat Developer & Consultant JBoss Inc xxxxxxxxxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
