Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
We're doing pretty well with Comet, the only thing comet is missing
is a non blocking write.
It is possible to do that without changing the API, in case it is
needed. It has a possibly significant cost howeve
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
We're doing pretty well with Comet, the only thing comet is missing
is a non blocking write.
It is possible to do that without changing the API, in case it is
needed. It has a possibly significant cost however (buffering all data
which can
Costin Manolache wrote:
Yes, 100 concurent requests is a sign you need lb - serving 1000 on
Sometimes it is desired to have the capability of serving 1000 concurrent
connections (not requests). The typical situation is when the frontend
server is used for delivering a static content with higher
Yes, 100 concurent requests is a sign you need lb - serving 1000 on
one server is a false problem in most cases. I would rather have a
server smartly reject requests and notify a lb rather then degrading
all requests by accepting more than it can handle properly.
Try adding a database access or s
2007/3/11, Costin Manolache <[EMAIL PROTECTED]>:
Great work - but I'm curious, wouldn't be better to explore the alternative
direction - i.e. detect when the server is too loaded and send a quick 502 ?
Maybe with some extra logic - like serve existing sessions first,
provide some notifications t
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Mladen Turk wrote:
Thanks everyone for the feedback, I'll let you know how everything
progresses.
Be sure to read the
http://www.faqs.org/rfcs/rfc1925.html :)
Regards,
Mladen.
---
Filip Hanik - Dev Lists wrote:
We're doing pretty well with Comet, the only thing comet is missing is a
non blocking write.
It is possible to do that without changing the API, in case it is
needed. It has a possibly significant cost however (buffering all data
which cannot be sent right away)
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Mladen Turk wrote:
(backlog)
For some reason, I have yet to see that backlog behave like it is
supposed to in Tomcat.
As my proposed long[] array is (supposedly) the same thing as the OS
backlog, maybe Filip can experiment with the "bac
Costin Manolache wrote:
Great work - but I'm curious, wouldn't be better to explore the
alternative
direction - i.e. detect when the server is too loaded and send a quick
502 ?
I totally agree, and the way its designed, this is totally doable. so
whenever the existing connection count is more t
Great work - but I'm curious, wouldn't be better to explore the alternative
direction - i.e. detect when the server is too loaded and send a quick 502 ?
Maybe with some extra logic - like serve existing sessions first,
provide some notifications that can be used by a load balancer ( or pager
:-)
Remy Maucherat wrote:
Mladen Turk wrote:
(backlog)
For some reason, I have yet to see that backlog behave like it is
supposed to in Tomcat.
As my proposed long[] array is (supposedly) the same thing as the OS
backlog, maybe Filip can experiment with the "backlog" attribute (by
default, it
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
The ultimate goal is to have 20k connections and still handle them
evenly.
The question is what will you do with those 20K connections.
The goal is that they will eventually get serviced, and that is the key.
in my test,
Mladen Turk wrote:
(backlog)
For some reason, I have yet to see that backlog behave like it is
supposed to in Tomcat.
As my proposed long[] array is (supposedly) the same thing as the OS
backlog, maybe Filip can experiment with the "backlog" attribute (by
default, it's only 100, but could
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
The ultimate goal is to have 20k connections and still handle them evenly.
The question is what will you do with those 20K connections.
The current servlet implementation as well as http protocol
is transactional (request/response), and presum
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
The processSocketWithOptions is a blocking call, hence you wont be
able to acccept new connections as long as your worker threads are
all busy.
Not entirely true.
What we need to do, is set the socket options, then simply add the
socket t
Henri Gomez wrote:
Great article !
I agree. But like Filip said, the entire NIO
(as well as APR) is sort of a hack.
It is obvious that the current JSE spec doesn't
fit for hybrid logic (both blocking and non-blocking)
because the cost of switching between them is simply
to high for any practic
Great article !
I wonder now what could be done when AJP is used instead of Coyote
HTTP connector ?
How does it fit ?
Regards
2007/3/9, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not su
Filip Hanik - Dev Lists wrote:
The processSocketWithOptions is a blocking call, hence you wont be able
to acccept new connections as long as your worker threads are all busy.
Not entirely true.
What we need to do, is set the socket options, then simply add the
socket to the poller waiting
correct, only 1GB of RAM, -Xmx512m for the Tomcat container.
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super tech
William A. Rowe, Jr. wrote:
Remy Maucherat wrote:
I don't really believe in this sort of solution (especially since APR
uses deferred accepts automagically).
To clarify, httpd 2.2 automagically adds default socket filters (data,
or http headers, where the platform supports them). AFAIK APR do
Remy Maucherat wrote:
>
> I don't really believe in this sort of solution (especially since APR
> uses deferred accepts automagically).
To clarify, httpd 2.2 automagically adds default socket filters (data,
or http headers, where the platform supports them). AFAIK APR does not
by default. If i
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super technical as I'm saving the juicy details for ApacheCon
And since no one reads my blog, I'll le
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super technical as I'm saving the juicy details for ApacheCon
And since no one reads my blog, I'll let you guys get it from here :)
Filip Hanik - Dev Lists wrote:
I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super technical as I'm saving the juicy details for ApacheCon
And since no one reads my blog, I'll let you guys get it from here :)
http://blog.covalent.ne
24 matches
Mail list logo
