I just committed what'll likely be the API (for the most part) in the
websockets branch. There's a little more lifecycle stuff to handle
(socket closures, e.g.) but i'm working on the chat sample now.
On 2/17/10 10:39 AM, Paul Sandoz wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>