Guys,
I missed the earlier email due to sysnet distraction. I will go through
the entire thread and come back here to provide my input around
protocol parser.
Stay tuned..
-hg
Jeanfrancois Arcand wrote:
>
>
> Scott Oaks wrote:
>
>> On Thu, 2007-11-29 at 10:19, Kristoffer Gronowski wrote:
>>
>>> 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.
>>
>>
>> So I think you're saying that a message-based parser is bad, and that a
>> parser that understands the state of the buffer is good? If so, that's
>> the underlying point about my proposal.
>>
>> But it is true that the simple implementation of what I've proposed will
>> lead to going through the buffer twice: once to find the boundary, and
>> once to understand the message. I used SIP as a test protocol for this,
>> and finding the boundary is quite fast, but a better parser would also
>> save some of that information for future use. So in fact, maybe what's
>> needed is both interfaces: the hasMessage/nextMessage so the parser can
>> let the grizzly framework know about when to read the buffer, and
>> something to get the message (already parsed) out of the buffer?
>
>
> Actually that looks good. One day we gonna have to support http
> pipelining and such api will be quite useful.
>
>>
>> Sailfin doesn't presently use the ProtocolParser and
>> ParserProtocolFilter -- are there plans to move to that?
>
>
> We played safe for the first integration and tried to re-use as much
> as possible what the OldNM was using. That's probably something we can
> do once Grizzly and AsyncQueue are integrated.
>
> Thanks
>
> -- Jeanfrancois
>
>
> I wasn't
>
>> actually sure from the sailfin source where the parsing is presently
>> done.
>> -Scott
>>
>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> 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
>