>
> Hi John,
>
> sorry to my late reply.
>
> Actually I have no idea and may be it simply because I am not strong
> enough
> to be a framework designer.
>
> As a user, I think Grizzly 1.x ProtocolParser is a little bit complicated.
> I
> have to spend some time to try and error... I cannot finish my parser
> myself
> based on the api doc. Instead, I have to search from net (You tutorial is
> a
> very good one) and ask for help in mailing list.
>
>
> Regards,
> Ken
Hi Ken,
no problem there is actually another Ken here on the list who
contributed ByteBufferStreams whom I had in mind when asking for advice ((-:
Many Greetings
John
>
>
>
> John ROM wrote:
> >
> > cc'ing to dev_at_grizzly.dev.java.net, because we might discuss this in
> > today's project meeting:
> >
> > Hi Ken,
> >
> > I just would like to get your opinion:
> >
> > As you know I'm integrating ByteBufferStreams into Grizzly 2.0
> >
> > Now on the Server side Alexey and I see 2 Usecases for the Reader of
> > ByteBufferStreams:
> >
> > In the first Usecase the StreamReader does not really need a
> > BlockingQueue.
> > As soon as bytes arrive they will be handed to StreamReader 's
> > receiveData() and the
> > same Thread will be consuming data with StreamReader 's getXXX Methods.
> >
> > I would like to just show you Server side pseudo-code to make it clear
> > (please forgive the uglyness ):
> >
> >
> > Transport.setMemoryManager(new SlabMemoryManager ());
> > chain.addFilter(new TransportFilter());
> > chain.addFilter(new ByteStreamFilter());
> > chain.addFilter(new CustomProtocolParserFilter ());
> >
> > The ByteStreamFilter basicly creates and holds onto a StreamReader per
> > Connection and calls
> > StreamReader.receiveData(..)
> >
> > And here's code Alexey proposed for the CustomProtocolParserFilter:
> >
> > class CustomProtocolParserFilter extends FilterAdapter {
> > private Attribute preparsedMessageAttribute =.....;
> >
> > public NextAction handleRead(Context ctx, NextAction action) {
> > Connection connection = ctx.getConnection();
> > CustomMessage preparsedMessage =
> > preparsedMessageAttribute.get(connection);
> > if (preparsedMessage == null) {
> > preparsedMessage = new CustomMessage();
> > }
> > StreamReader reader = ((Stream) ctx.getMessage()).getReader();
> > int parsingState = preparsedMessage.getParsingState();
> >
> > while (isParsing) {
> > switch (parsingState) {
> > case 0:
> > if (reader.isAvailable(4)) {
> > preparsedMessage.setA(reader.getInt());
> >
> preparsedMessage.setParsingState(++parsingState);
> > } else {
> > isParsing = false;
> > }
> > break;
> > case 1:
> > if (reader.isAvailable(8)) {
> > preparsedMessage.setB(reader.getLong());
> >
> preparsedMessage.setParsingState(++parsingState);
> > } else {
> >
> > isParsing = false;
> > }
> > break;
> > case 2:
> > if (reader.isAvailable(2)) {
> > preparsedMessage.setB(reader.getShort());
> >
> preparsedMessage.setParsingState(++parsingState);
> > } else {
> > isParsing = false;
> > }
> > break;
> > case 3:
> > if(reader.isAvailable(1)) {
> > preparsedMessage.setB(reader.getByte());
> >
> preparsedMessage.setParsingState(++parsingState);
> > } else {
> > isParsing = false;
> > }
> > break;
> > }
> > }
> >
> > if (parsingState < 3) {
> > preparsedMessageAttribute.set(connection, preparsedMessage);
> > action.setNextAction(RETURN); // Didn't complete message
> > parsing
> > } else {
> > ctx.setMessage(preparsedMessage);
> > }
> >
> > return action;
> > }
> > }
> >
> >
> > In this second usecase I want to make use of the StreamReader's
> > BlockingQueue.
> > Grizzly just becomes a producer for the StreamReader and hands of the
> > StreamReader to the Domain Logic Layer which will be running in a
> seperate
> > Thread.
> > So again you set up:
> >
> > Transport.setMemoryManager(new SlabMemoryManager ());
> > chain.addFilter(new TransportFilter());
> > chain.addFilter(new ByteStreamFilter());
> > chain.addFilter(new DomainLogicFilter ());
> >
> > Now a DomainLogicFilter only gets called once per connection and hands
> > over a Reader to the Domain Logic Layer. From then on Grizzly will just
> > call Reader.receiveData(..) and go back waiting for
> > Read Events.
> >
> > Actually I would like Grizzly to support this usecase out of the box.
> > In the moment I think you would have to provide a framework way to
> > configure a DomainLogic running ThreadPool and also you would need to
> > provide a easy way to define a ByteStreamFilter Protocol which basicly
> > just enables having n Readers per connection.
> >
> > I just would like to get your feedback because maybe this second usecase
> > is too special and one
> > should just implement the first usecase and let users construct their
> own
> > solution with the ByteBufferStream classes available in Grizzly 2.0
> >
> > Many Greetings
> > John
> >
> > --
> > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit
> allen:
> > http://www.gmx.net/de/go/multimessenger
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/ByteBufferStreams-integration-question-tp20581393p20685265.html
> Sent from the Grizzly - Development mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger