On 14 July 2012 02:38, Scott Ferguson <ferg_at_caucho.com> wrote:
> On 07/12/2012 06:26 PM, Greg Wilkins wrote:
>>
>> On 13 July 2012 09:25, Danny Coward <danny.coward_at_oracle.com> wrote:
>> I think that both 1 and 2 can be provided as a layer above 3B.
>
>
> You can't really layer (2 nonblocking) above 3b (or 3a).
>
> It either requires buffering the entire message, or messy threading.
Option 2 requires difficult threading decisions no matter what.
When onMessage(InputStream message) is called, then the caller has to
be prepared that this will be a long running call with the thread
blocking as it calls read methods on the input stream. So the caller
would be wise to dispatch a thread to do this.
Option 2 over 3B is just moving that dispatch up a level. There will
be a handler that will be receiving callbacks on partial messages - on
the first of these it will create a stream object and dispatch a
thread to handle it with a onMessage(InputStream message) call. On
subsequent partial message callbacks, it will feed the data into that
stream that will probably wake up the blocking dispatched thread.
The problem with this is that if the on partial message callbacks are
already dispatched (because we are running in MUX for example), then
we have a double dispatch to handle the message. However the
layer can be smart for small messages - if the first partial message
callback has last=true, then it can use it's own thread to call the
onMessage(InputStream).
For large fragmented messages, it is hard to avoid the double dispatch
- unless we start imposing contracts on the partial message callbacks
- saying they must be non-blocking implementations that return quickly
OR copy/dispatch if they wish to defer processing. That kind of
contract might be OK inside an implementation, but is a bit tough as
an application API.
Hence while 2 may be a layer on top of 3B, it is probably a layer that
should still be implemented within our API implementation, as it can
be done more efficiently there and we don't expose nasty contracts to
applications.
ie I'd be happy for us to expose 1, 2 and 3B APIs if we want to be all
things to all people. If we want to avoid a fat API, then 3B is the
one that is most fundamental as 1 & 2 can be derived from it (albeit
it with some inefficiencies).
cheers
--
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.