Remy Maucherat schrieb:
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).
You are right.
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.
Well, I don't know what you understand under polling. I guess you mean
the clients will have to sent GET and POST requests repeately, right?
The load is going to be even higher with polling. That's I would not
introduce any polling. How would I do this anyway, if I only use HTML?
My idea was opening a connection and then just let the client wait and
sit there. Whenever I get new messages, then I will sent them over.
Here a diagram:
Client sends GET -> Server
Server sends HEADERS (Content Encoding: Chunked) -> Client
Server sends chunks -> Client
Client displays them whenever they arrive.
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.
Well actually you caught me here. You are right. I mean I have tested it
and after the doGet() and doPost() methods returned the connection was
closed. But you are absolutely right, that this can't be a general
policy and indeed depends on the keepalive timeout. So I have to check
this out, it could actually be the solutions for my problem at least
when it comes to saving the threads for each conneciton.
I could just remember the HttpRespone Objects and use one thread, which
gets, when new messages arrive in the queue. The thread then could
println() them to all he HttpRespones. This would save me all the
Threads. Hmm, sounds good, or have I missed somthing?!
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.
What do you mean with polling? I mean none of the threads is polling
using this method, or? For example 5000 Threads would be waiting. Then a
message arrives and all of them get notified and then they sent the
message to the clients. So I don't see where polling comes in?!
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Inc
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
