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.
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.
> Hence, the current implementation works only if the socketread has a
> single, complete message that can be passed to the next filter.
>
> 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).
>
> 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.
>
> 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?]
>
> -Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>