Hi!
The problem is that how do you know that the ByteBuffer bb contains an
entire message.
We have the SIP parser in Sailfin and for UDP this is the case but for
TCP/TLS you could have:
One fraction of T, one T or 1 1/2 T.
And to know you have one T and where to stop you would have to frame the
message and it's half of the parsing.
BR Stoffe
-----Original Message-----
From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
Sent: den 29 november 2007 16:14
To: dev_at_grizzly.dev.java.net
Subject: Re: Protocol Parser proposal
charlie hunt wrote:
> We should probably solicit some input from Harsha or look at his
> webrevs for the work he's done on integrating Grizzly with
GlassFish-CORBA.
> Perhaps Harsha can share with us a link to his webrevs?
>
> AFAIK, Harsha is the one who would be the most impacted by the change
> to ProtocolParser. I don't know of anyone else who is using it. If
> someone knows otherwise, please speak up.
Harsh is probably the only one that used that API :-) Since his
implementation is not final, I would think we should apply Scott
proposal and then cut the 1.7.0 tomorrow.
>
> I may want to think about the "parse bytes and execute" versus "parse
> bytes and dispatch to another thread" approaches. Prior to the
> optimized read, we used to do the former. Btw, it's probably not
> obvious that there is another queue involved in GlassFish-CORBA which
> a Message passes through prior to getting to the encoding /decoding
layer.
>
> charlie ...
>
> Scott Oaks wrote:
>> I've been looking a lot at the protocol parser and related classes in
>> the last few days and have a proposal for a different sort of
interface.
>>
>> The present interface (com.sun.grizzly.ProtocolParser) is based on a
>> parser that returns abitrary messages:
>> public T parseBytes(ByteBuffer bb)
>>
>> But if the parser is called from the grizzly framework (e.g. from
>> com.sun.grizzly.filter.ParserProtocolFilter), nothing really can be
>> done with the returned message. The ProtocolParser has methods to set
>> the buffer position and limit around the message, but if there are
>> multiple message in the buffer, there's no good way to pass a single
>> message along the filter chain or do any other developer interaction
with them.
Agree.
>> Hence, the current implementation works only if the socketread has a
>> single, complete message that can be passed to the next filter.
My background with http is following me :-)
>>
>> What I propose is changing the ProtocolParser interface to this:
>> public interface ProtocolParser {
>> public boolean isExpectingMoreData(); // parser has a partial
>> message
>> but needs more data
>> public boolean hasMoreBytesToParse(); // parser has data --
>> maybe a full or partial message
>> public boolean hasNextMessage(); // parser has a
>> complete message and knows its boundaries
>> public void getNextMessage(); // parser
should
>> set up the buffer to reflect next message
>> public void setBuffer(ByteBuffer); // buffer on
which
>> parser should operate
>> public void releaseBuffer(); // parser
>> shoud setup buffer for next read
>> }
>>
>> This would allow ParserProtocolFilter to be written so that in its
>> execute() method, it calls getNextMessage, and the buffer can be
>> passed along the filter chain for futher processing. Then its
>> postExecute() method can see if there is more pending data, and if
>> so, it can signal that the default processing loop should reinvoke
>> (so the next message is parsed and passed down the filter in turn).
+1
>>
>> I actually have that all working, but one potential downside to this
>> is that multiple messages received in a single read call are
>> processed by a single thread; CORBA presently can process each
>> message on a different thread. In the code I was prototyping, I
>> actually wanted the single-thread per socket read behavior, but I can
>> see where both are useful. The CORBA-type behavior is more suited to
>> the existing
>> (message-based) interface; it still requires some way for the
>> protocol filter to dispatch the message -- in which case, perhaps the
>> ProtocolParser needs to have an associated filter list itself or
>> something? Or maybe there needs to be a sync/async flag to control
>> how the messages get dispatched? At any rate, that path would also
>> require some changes to the interface and to the existing
ParserProtocolFilter.
Can you post the entire patch?
>>
>> So I'd instead propose we go with the changed interface (or that
>> there be two interfaces, and someone address the message-based one
>> implementation). [Or maybe there's a way to combine them that I'm
>> just not seeing?]
I think we should explore your complete patch and make sure the Corba
team agree with the change. Since they are using 1.6.1, there build will
not breaks until they switch to 1.7.0 :-)
What other think?
Thanks
-- Jeanfrancois
>>
>> -Scott
>>
>> ---------------------------------------------------------------------
>> 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: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-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