dev@grizzly.java.net

Re: Grizzly 2.0: Standalone filterchain processing example

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 22 Sep 2008 15:24:01 -0400

Salut,


Oleksiy Stashok wrote:
> Hi,
>
> currently I'm working on subj implementation and have something completed.
> Please take a look at the example [1].
>
> It's simple example, where you can read/write Strings directly, using
> standalone filterchain processing.
> What do you think?
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1]
>
> public class FilterChainTest extends TestCase {
> public static final int PORT = 7778;
>
> public void testStandaloneFilter() throws Exception {
> Connection connection = null;
> TCPNIOTransport transport =
> TransportManager.instance().createTCPTransport();
> transport.getFilterChain().add(new TransportFilter());
> transport.getFilterChain().add(new UTFStringFilter());
> transport.getFilterChain().add(new EchoFilter());

We still need to discuss the getFilterChain() names ;-)


>
>
> try {
> transport.bind(PORT);
> transport.start();
>
> ConnectFuture future = transport.connectAsync("localhost",
> PORT);
> connection = (TCPNIOConnection) future.get(10,
> TimeUnit.SECONDS);
> assertTrue(connection != null);
>
>
> String message = "Hello world!";
>
> FilterChain filterChain = transport.getFilterChain();
>
> WriteResult result = filterChain.write(connection, message);
> assertEquals(result.getMessage(), message);
>
> ReadResult readResult = filterChain.read(connection);
>

OK I'm not sure about this example. It seems we first works with the
Transport object and then switch to the FilterChain. If the FilterChain
handler the read/write logic, why not the connectAsync be on the
FilterChain as well?

Also, the connet() operations returns A Future, where read/write return
a Read/WriteResult. Should read/write return a Future as well? I would
propose we unify the API so any async operations like connect/read/write
return a Future. From the Future, we can return a Result, which contains
the requested information. Something like:


Result result = ConnectFuture.get()
Connection connection = result.getResult()

or

Connection connection = ConnectionFuture.get(..) //No cast needed
ReadResult result = ReadFuture.get();
WriteResult resukt = WriteFuture.get();

So your example seems to "suffer" 2 issues:

+ Need one single Object to interact with.
+ Unify API for async operations.



> String responseMessage = (String) readResult.getMessage();
>
> assertEquals(message, responseMessage);
> } finally {
> if (connection != null) {
> connection.close();
> }
>
> transport.stop();
> TransportManager.instance().close();

I still find it dangerous to have 2 operations to execute here :-) But
maybe it is only me :-)

A+

-- Jeanfrancois



> }
> }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>