Hi Justin,
first of all, thank you very much for websockets implementation!
> 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.
Agree, IMO the important thing here is to provide some higher level
API for dealing with websockets. Hide low-level details as much as
possible.
> 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
>
Just my 2 cents :)
WebSocketsEngine as analog of CometEngine - agree. So it will be some
centralized registry for WebSocketsApplications.
WebSocketsApplication will process websockets connected to a specific
URI:
WebSocketsApplication {
Set<WebSocket> getConnectedWebSockets();
onOpen(WebSocket newWebSocket);
onMessage(WebSocket webSocket, SomeMessageType message);
onClose(WebSocket webSocket);
}
WebSocket - represents particullar web socket connection.
> 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.
Right.
> 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.
IMO we have to use worker thread pool. Not sure why we may want to
separate HTTP traffic from websockets traffic. For sure Websockets
have to leverage NIO, and do not block during I/O operations.
> 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.
IMO it's not needed.
Thanks!
WBR,
Alexey.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>