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.
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.
On 2/17/10 8:13 AM, Paul Sandoz wrote:
> On Feb 16, 2010, at 4:37 PM, Justin Lee wrote:
>
>> This morning I committed basic support for websockets to the trunk.
>> It's located in modules/websockets and is more or less ready to be
>> played with. There are a few basic unit tests included. Probably
>> the most interesting is WebSocketFilterTest.testSimpleConversation.
>> It's a servlet-based approach in which the servlet is largely unaware
>> of the underlying websockets work. This works well enough, but it
>> does impose a slight burden on the servlet author. This attempted
>> complete transparency does lead to a little bit of awkwardness in
>> use, however.
>>
>> So now that it's working, we'll be doing some work on the API itself
>> to provide a cleaner way to register your components for use in a
>> websockets conversation.
>
> Great stuff.
>
>
>> So please play with it and give some feedback. We'd like to have a
>> nice, clean API we can all live with so if you have any input now's
>> the time. I'll be looking over what jeanfrancois has done with
>> atmosphere and jetty to see how much we can borrow
>
> I guess it depends on what you mean by "borrow" w.r.t. atmosphere. If
> it means copy from atmosphere then i would strongly suggest not and
> instead lets integrate with atmosphere, making changes as appropriate
> either way, as there is way more value in doing that. Especially at
> the higher level such that JAX-RS and Jersey can be leveraged and
> utilized with many useful Atmosphere features.
>
> Paul.
>
>
>> . Any suggestions are completely welcome. I want this to be useful
>> and usable for someone other than myself. :)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>