Hi Sébastien,
my example does not really work for you.
It is an example of How-to write a fixed length Protocol. You could use
it for the transport to your feed server since it has some features you could use, but
that is not the topic of your migration guide ((-:
I think the SuspandableFilter could really work out for you. You may have to extend it,
but since you are connecting to another 3th party Server you could really programm with
no blocking at all. That's terrific!
In my case I have to wait for a Jdbc Connection. I can plugin a queue and a Threadpool but
still somewhere in the chain there will be a blocking Thread.
So it turned out for me that I need to share state between Threads and so the best
Grizzly can do or me is to simplify sharing the Grizzly Context.
Many Greetings
John
> Salut,
>
> Oleksiy Stashok wrote:
> > Hi,
> >
> > think you're right, SuspandableFilter could help here.
> > What we miss, IMHO, it's good example how it could be used.
> >
> > John, I know you're working on some async request processing, do you
> > have any example to share? :)
>
> Nice to see reply from you ...you are back :-) I will finish my blog on
> "Extending the Grizzly..." today and will write an example. We might
> also want to write sample on how to use the Context resume/suspend
>
> A+
>
> -- Jeanfrancois
>
>
> >
> > Thanks.
> >
> > WBR,
> > Alexey.
> >
> > On Jul 6, 2008, at 13:47 , Survivant 00 wrote:
> >
> >> I want to know how to fix my problem. here the context.
> >>
> >> I have parserProtocol that will parse the buffer and the next Filter
> >> will receive a valid String.
> >>
> >> the String is my command to do.
> >>
> >> so in MyProtocolFilter I'll have that :
> >> String query = (String)
> context.removeAttribute(ProtocolParser.MESSAGE);
> >>
> >> after that I'll launch the process to do
> >>
> >> like : if(query.equals("sample1")){ sample1Command.process();}
> >>
> >> sample1Command.process will create a CommandRequest and a
> >> CommandResponse, and send this request to a 3th party (could be
> >> anything). The 3th party will process the request and send back the
> >> response by the CommandResponse.handleResponse(response);
> >>
> >> and the CommandResponse.handleResponse(..) will send this response to
> >> the client.
> >>
> >> here a sequence.
> >>
> >>
> >> client -> message to the server
> >>
> >> server :
> >> MyQueryProtocolFilter (parse the queries)
> >> MyProtocolFilter ->
> >> create a Command
> >> send the query to the 3th party ->
> >> 3th : send back the response <-
> >> reponsehandler.handle(..) : send back the response to the
> >> client<-
> >>
> >> I don't want to block the threadpool when waiting for the response
> >> from the 3th party.
> >>
> >> (I think I can use a SuspendableFilter right ? )
> >>
> >> and the other thing.. how to send to response to the client ?
> >>
> >> Should I have to pass the context to the Command ?
> >>
> >> without Grizzly, I was keeping the SocketChannel, and the response
> >> send the response to the client using that..
> >>
> >> but with grizzly, not sure if I had the best idea ? any comments ?
> >>
> >>
> >> I tought of using that in the CommandResponse
> >>
> >> void handleResponse(String response){
> >> // Depending on protocol perform echo
> >> SelectableChannel channel =
> context.getSelectionKey().channel();
> >> try {
> >>
> >> ByteBuffer writeBuffer =
> >> ByteBuffer.allocateDirect(response.length());
> >>
> >> writeBuffer.put(response.getBytes());
> >>
> >> writeBuffer.flip();
> >>
> >> if (context.getProtocol() == Controller.Protocol.TCP) { //
> >> TCP case
> >> OutputWriter.flushChannel(channel, writeBuffer);
> >> }
> >> } catch (IOException ex) {
> >> throw ex;
> >> }
> >>
> >> }
> >>
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger