It is always possible to build an applet. It should be able to do the
networking the right way, and I just tested a small program that just
forks n threads in java. the thread sleeps for 10s then print something.
3000 of these threads took 655 MB on freeBSD box, and only little cpu.
regards,
TP
If the thread servicing your request blocks, the browser will not quit.
The browser would wait the min( browser time-out ,response stream is
closed). this is the trick many people use.
doGet(request, response){
out = response.getOutputStream();
// when you write something
out.write(by
I think everybody on the list here agrees that http is not the right
sort of thing for a chat application. And most of the IM/chat
applications do not run on http anyway. opening the sockets directly
for such an application is better/easier any day.
However, people do demand an HTTP
Tp wrote:
Well, that's a good question. The outcome of this thread might be just
that. But it would have been nice to use existing software
infrastructure.
Maybe look at the IRC protocol ? Has existing infrastructure, heritage
and eco-system.
http://www.irchelp.org/irchelp/rfc/
http://www
On 4/3/06, Tp <[EMAIL PROTECTED]> wrote:
> Also the reference to the OutputStream itself? I mean it should stay
> open until the connection closes. Are you sure?
This OutputStream object is a fake facade, and loses its relationship
to the actual socket at the end of the request.
--
xx
David Delbecq schrieb:
Here a diagram:
Client sends GET -> Server
Server sends HEADERS (Content Encoding: Chunked) -> Client
Server sends chunks -> Client
Client displays them whenever they arrive.
Just one point. If your 'client' is a classical browser it won't work
like this out of the box,
Remy Maucherat schrieb:
On 4/3/06, Tp <[EMAIL PROTECTED]> wrote:
Remy Maucherat schrieb:
But you said that the connection will not close, when the doGet() or
doPost() method returns, which of course make a lot of sense. Otherwise
Persistent connections would not be possible at all.
So if that'
On 4/3/06, Daniel Guggi <[EMAIL PROTECTED]> wrote:
> Hi!
> >
> > Right. I said you need to use polling, or use 5000 threads (which is
> > not a problem if you have enough memory).
> >
> Are you sure that 5000 threads is not a problem when you have enough
> memory. I'd be worried about wasting lots
On 4/3/06, Tp <[EMAIL PROTECTED]> wrote:
> Remy Maucherat schrieb:
> But you said that the connection will not close, when the doGet() or
> doPost() method returns, which of course make a lot of sense. Otherwise
> Persistent connections would not be possible at all.
>
> So if that's true, then I sh
>
> Here a diagram:
>
> Client sends GET -> Server
> Server sends HEADERS (Content Encoding: Chunked) -> Client
> Server sends chunks -> Client
> Client displays them whenever they arrive.
Just one point. If your 'client' is a classical browser it won't work
like this out of the box, for the simp
Hi!
>
> Right. I said you need to use polling, or use 5000 threads (which is
> not a problem if you have enough memory).
>
Are you sure that 5000 threads is not a problem when you have enough
memory. I'd be worried about wasting lots of cpu because of
context-switching???
lg
-
Remy Maucherat schrieb:
On 4/3/06, Tp <[EMAIL PROTECTED]> wrote:
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 polli
> >
> > Why then using tomcat at all? What's wrong with writing own app, which
> > listens on a socket and does whatever it has to do? Before you have to
> > rape tomcat to perform a task it was never designed for...
> >
>
> Well, that's a good question. The outcome of this thread might be just
> t
On 4/3/06, Tp <[EMAIL PROTECTED]> wrote:
> 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
On 4/3/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> Why then using tomcat at all? What's wrong with writing own app, which
> listens on a socket and does whatever it has to do? Before you have to
> rape tomcat to perform a task it was never designed for...
Yes, indeed. In many cases, it would s
Leon Rosenberg schrieb:
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
Remy Maucherat wrote:
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.
How about bypassing the servlets alltogether?
we
Rajeev Jha schrieb:
Remy Maucherat wrote:
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.
How about bypassing the servlets alltogether?
we can take any exisitng http/ajp13 connector code and rep
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
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
>
> >
> >
> >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.
> >
> >
> >
> How about bypassing the servlets alltogether?
> we
Remy Maucherat wrote:
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.
How about bypassing the servlets alltogether?
we can take any exisitng http/ajp13 connector code and replace the
servlet con
Remy Maucherat wrote:
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
Tp wrote:
And there seems to be no workaround, because the connection will close
after the doGet() and doPost() method finishes (is that actually
true?). So, the only way to keep 3000 simultaneous connections is to
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 implemen
David Delbecq schrieb:
Tp a écrit :
Hi,
we have to develop a high performance chat based only on HTML and HTTP
only for a television company. The chat's output window requires one
open HTTP connection per client, which means that you need at least
3000 simultaneous ie. open HTTP connections f
Remy Maucherat schrieb:
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
Tp wrote:
And there seems to be no workaround, because the connection will close
after the doGet() and doPost() method finishes (is that actually
true?). So, the only way to keep 3000 simultaneous connections is to
keep
On 4/3/06, Rajeev Jha <[EMAIL PROTECTED]> wrote:
> Tp wrote:
> > And there seems to be no workaround, because the connection will close
> > after the doGet() and doPost() method finishes (is that actually
> > true?). So, the only way to keep 3000 simultaneous connections is to
> > keep 3000 of thos
Rajeev Jha schrieb:
Tp wrote:
And there seems to be no workaround, because the connection will close
after the doGet() and doPost() method finishes (is that actually
true?). So, the only way to keep 3000 simultaneous connections is to
keep 3000 of those methods from returning, wehich means
Tp wrote:
And there seems to be no workaround, because the connection will close
after the doGet() and doPost() method finishes (is that actually
true?). So, the only way to keep 3000 simultaneous connections is to
keep 3000 of those methods from returning, wehich means keeping 3000
thread
Tp a écrit :
> Hi,
>
> we have to develop a high performance chat based only on HTML and HTTP
> only for a television company. The chat's output window requires one
> open HTTP connection per client, which means that you need at least
> 3000 simultaneous ie. open HTTP connections for 3000 chatters
Hi,
we have to develop a high performance chat based only on HTML and HTTP
only for a television company. The chat's output window requires one
open HTTP connection per client, which means that you need at least 3000
simultaneous ie. open HTTP connections for 3000 chatters.
To the former pos
29 matches
Mail list logo
