On Feb 17, 2010, at 3:37 PM, Justin Lee wrote:
> I'm thinking we'll need something along the lines of comet's handler
> classes. Being able to register a handler and listeners and the
> like opens up a lot of options. For example, currently the chat
> demo can't be nicely ported because we don't/can't keep track of all
> the websockets opened up to the system. So at a rough pass here are
> some of the objects I'm thinking we'll need:
>
> * WebSocket (probably an interface so we can mock out portions for
> testing) -- this would, of course, handle all de/framing issues
> when reading/writing and notify the listeners of events
> * WebSocketListener -- listens and handles events
> * WebSocketHandler -- performs the actual operations needed
> * WebSocketContext -- general meta class that could, for example,
> keep track of all the open sockets for a given URI for broadcast/
> push operations
> * WebSocketEngine -- this would serve as the base entry point for
> processing WS connections. This would serve to register contexts,
> e.g., and create WebSocket instances based on the appropriate scheme
>
> I'm not 100% on all of this but between looking over the grizzly
> comet stuff, talking to jeanfrancois about his work with jetty's
> implementation and atmosphere, and looking at other implementations,
> I think something along these lines is probably what we'll end up
> with.
OK. A low-level approach such as that makes sense to me. Alexey and
other Grizzly developers are in a much better position than I to
comment on the specifics.
My concern is we should try and avoid duplicating stuff that is
already in Atmosphere and instead plug into it for such requirements,
and it should be easy to plug in to. But from what i gather there will
be no such duplication.
> I'm by no means married to this approach though it's what I'll
> start with unless there's some huge outcry. I plan on branching
> today to play with this so any feedback is certainly welcome.
>
> I go back and forth about how to handle processing the websockets
> threading wise. Currently it uses the same threadpool as the async
> executor which, i think, is just the general worker thread pool.
> I'm wondering if we shouldn't use a (semi)private threadpool and
> selector in either the engine or the context to manage these
> connections. It might be ok to reuse the common worker thread pool
> but I'm afraid of consuming all the threads for HTTP traffic while
> processing these websocket requests. For now, i'll just continue to
> reuse what we have but I'd really like some feedback there. I'd
> hate to have to reimplement so much of the NIO processes (that was
> one of the problems with the original websockets code) but it might
> be beneficial to move some of this processing off the main pathways
> so that normal HTTP processing isn't affected too much.
Excuse my ignorance but on this particular matter how would WebSocket
be any different to the demands of say Comet+Bayeux in this respect?
Paul.