Thanks Remy...
I have a better understanding of your concerns. I see your points now.
Sorry it takes a bit of back and forth and thinking for somethings to think
especially if you have been thinking about something for a while in a
different direction....
Thanks...
comments below....
On Wed, Oct 5, 2011 at 3:39 PM, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> On Wed, 2011-10-05 at 08:34 -0700, Rick Hightower wrote:
> A stream API with blocking IO (InputStream and OutputStream are blocking
> IO) may block while waiting for more data for the current frame on
> input, or while the client is backlogged on output. To solve this, extra
> APIs are needed, like we are trying to add for the stream APIs in
> Servlet 3.1.
>
Right. Since the needs are similar perhaps we can use those APIs as a
starting point.
I found the proposal and read through it a few times. WRT to NIO Servlet
support.
To be specific....
http://java.net/projects/servlet-spec/lists/jsr340-experts/archive/2011-09/message/25
There is probably some additional abstraction and/or duplication that needs
to be done so this style supports both WebSockets and Servlets.
>
> Syncing is expensive, and there's no reason for it to be automatic, this
> hurts performance for no reason. If the user needs it because he somehow
> thinks writing from multiple threads is such a great plan, syncing on
> the context object is trivial. The same design is in Servlet 3 when
> async is used (sync if needed to avoid corruption).
>
> The goal is that the IO of a webapp is done with two threads (one for
> input, one for output), so there are really no syncs needed, and, as a
> result, ideal scalability.
>
Ok. I agree with that. Good point about just syncing the context. This makes
the whole thing less magical and more explicit. Transparency is a good idea.
Thanks.
I'll do another write up with this in it.
> >
>
> So that's not the right threading model, it doesn't scale very well.
> Essentially, you need some event gathering (as async threads or
> callbacks from some other container), two threads for IO, and the rest
> of the callbacks from the container threads about messages on input.
>
Agreed let's move to the NIO streams. Good points. Thanks.
>
> --
> Remy Maucherat <rmaucher_at_redhat.com>
> Red Hat Inc
>
>
Coming up with a second proposal.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>