On Thu, Jul 12, 2012 at 6:23 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> As the API stands, each Endpoint handles the lifecycle events of its
> multiple peers, there is a choice as to whether to say that the
> implementation is allowed to call Endpoint methods concurrently, or
> sequentially. The latter might be more convenient for developers; and may
> not 'cost' too much in scalability since one could argue that
> connect/disconnect events are not so common as, say, messages going back
> and forth.
>
Connect messages may not be as common, but they can often be heavier
as initialization type logic is performed (e.g. load user data from a
database, establish a connection to a backend service, etc).
>
> And if the developer uses a separate MessageListener instance per Peer (as
> the API suggests), then the onMessage methods on each instance are only
> ever called sequentially (assuming I'm correct that the websocket protocol
> is designed with only one message at a time per socket).
>
> Would that approach, essentially meaning that only one container thread at
> a time hit the connect/disconnect and onMessage callbacks at a time an
> acceptable balance of developer convenience and scalability ?
>
> Or should we think of specifying something more like the servlet model,
> where connect/disconnect and onMessage callbacks could be called
> concurrently by multiple threads. More of a burden on developers, and would
> probably need some rejigging of the API.
>
I think we need to support both models. Apps that make use of shared
in-memory structures are better suited to a single thread, to simplify
coordination. Whereas apps that make use of blocking IO, services, heavy
computation, etc, would be better suited to starting their own thread.
How about...
* the initial connection event always occurs on the same thread
* user handlers have the option of continuing to process on the same
thread, or spawning a new thread to process the connect / onmessage /
disconnect
* the API provides a mechanism for spawning the new thread (backed by
vendor specific implementation, e.g. thread pool)
-Joe