Scott,
I think we are generally agreeing here - except perhaps about the cost
of an extra dispatch. I don't think the extra dispatch is a huge
issue as it will only be incurred for large fragmented messages, were
I doubt the extra cost of a dispatch will be significant, even at
scale. But still it is best avoided and am happy to accommodate
streams in the API so that implementations can be smart.
With regards to a higher level object queue, I do agree that there are
benefits if such a thing can be achieved. But the problem is how do
we generally serialize/deserialize objects in an asynchronous way.
If it can't be done asynchronously, then it does not matter if the
protocol or the application does it - both will have to aggregate
until the entire message is available to be serialized/deserialized.
I can see that there is probably benefit in providing UTF-8 partial
messages, as that conversion is well defined and the protocol can
deserialize all the complete characters it has and just remember any
unused bytes between frames. But I don't see how this can be done
generally for Objects unless we mandate our JSON mappings and provide
an async implementation of that.
cheers
On 14 July 2012 08:08, Scott Ferguson <ferg_at_caucho.com> wrote:
> On 07/13/2012 02:02 PM, Greg Wilkins wrote:
>>
>> 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.
>
>
> No, it's not "just moving the dispatch up a level". As you point out, Option
> 2 over 3B introduces an extra wake/unpark overhead for each packet. (And
> probably an extra thread.)
>
>
>> 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.
>
>
> That's my point.
>
> 2 over 3B is not just a simple adapter layer. It's expensive.
>
> (Related to threading efficiency issue is why I'd suggested a higher level
> object (json) queue for reading and writing. Since the websocket
> implementation already needs to deal with threading issues -- particularly
> with mux -- it's better positioned to handle the required thread dispatch
> efficiently.)
>
> -- Scott
>
--
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.