Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
Received-SPF: pass (athena.apache.org: domain of james.w.todd@gmail.com
 designates 209.85.214.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Bjk5KplUulc6AjFoApIX6YhAYo2tpVPGsxjo23znqjomO44xXqZ1ucXf052BOdk9q0
         2YiS/PQu42/hpOt5/sQWo1ZcNW5Pyld4Z9OkLEQ43ksxn4eWr3Cf5x3O4G36bYRPljMn
         i+KjHFeToJx/fiiQetOmizfOcoH0K/pklWWQA=
MIME-Version: 1.0
In-Reply-To: <AANLkTim7_E3I3VgTeO8Z1n8OSwJHzp2OOhBfmn7feYeh@mail.gmail.com>
References: <AANLkTin5cvJuMYz6McKjg2Lw8A251qPB5zQeSq3dBYIc@mail.gmail.com>
	<4C23A8EB.4090300@apache.org>
	<AANLkTik2YXiG9R936LS24rkiQONyxET_k_NOT7Ynui2s@mail.gmail.com>
	<AANLkTimo_MFfORJ16Ym-Q_D5ODQ05kwfrWTOrilyMZ7W@mail.gmail.com>
	<AANLkTik8oE86SnRs7MOkGoemqEJ0c5ZNEKRwVZnXIpMr@mail.gmail.com>
	<AANLkTilGd6BnLDUBlTyi3uiuLyIaDcGkudEfU4jAqR4k@mail.gmail.com>
	<AANLkTim7_E3I3VgTeO8Z1n8OSwJHzp2OOhBfmn7feYeh@mail.gmail.com>
Date: Fri, 25 Jun 2010 11:58:10 -0700
Message-ID: <AANLkTilDk08bEam0OwCsFZmKQ7lly-PmZDZZGHuKkFRE@mail.gmail.com>
Subject: Re: Avro RPC implementation using Netty
From: James Todd <james.w.todd@gmail.com>
To: dev@avro.apache.org
Content-Type: multipart/alternative; boundary=000325574cb2356e8b0489df5ad3

--000325574cb2356e8b0489df5ad3
Content-Type: text/plain; charset=ISO-8859-1

saw that. i will dive in.

i am curious as to your thoughts regarding my response. i think the
differences are 1) philosophical [eg simple external api as a principal
objective] and 2) tactical [eg internal implementation details].

optimally, we can collectively meld the ideas for an overall improved
solution.

there is still outstanding work regarding the responder delegation work that
is assumed to be follow on work for patch i provided.

thoughts?

- james

On Fri, Jun 25, 2010 at 11:46 AM, harry wang <coolwhy@gmail.com> wrote:

> hi, I just attached my implementation patch as another choice for trial at
> https://issues.apache.org/jira/browse/AVRO-405. :)
> Maybe we could get a better result in the end.
>
> regards
>
> - harry
>
> On Sat, Jun 26, 2010 at 2:24 AM, James Todd <james.w.todd@gmail.com>
> wrote:
>
> > hey harry -
> >
> > glad to hear there is functional parity :)
> >
> > it will be good to get this initial issue in one way or another.
> >
> > i opted to leverage the netty internals to manage/contain the discreet
> > steps
> > in the pipeline but admittedly they are trivial and can in all likelihood
> > be
> > rolled up. i am keen on implementing bruce's proposed protocol and
> perhaps
> > this objective led me to this design. regardless it is solely internal
> and
> > up for refactoring.
> >
> > there is one significant TODO in the patch i provided which is to
> > internally
> > determine the relevant responder by inspecting the handshake data and
> > delegating accordingly. that is work that is assumed
> > to go along with this patch and work worth doing imo, as the data is all
> > available and it streamlines/simplifies the external api.
> >
> > to summarize, error on the side of simplest possible external api (noting
> > the afore mentioned responder delegation work) and allow for (possibly
> > speculative) implementation variability for the internal details.
> >
> > i also didn't necessarily strive to align w/ other implementations
> > (ie SocketTransceiver/SocketServer or HttpTransceiver/HttpServer) as i
> > didn't see that as significantly advantageous to do so. guess i could be
> > wrong.
> >
> > thoughts?
> >
> > best,
> >
> > - james
> >
> > On Fri, Jun 25, 2010 at 4:23 AM, harry wang <coolwhy@gmail.com> wrote:
> >
> > > Hi james, after studying your works, I find that our basic idea is
> alike
> > > but
> > > our implementation is a little different. It appears my design is
> simpler
> > > than yours. The following is the comparison:
> > >
> > > 1, my design only has 4 files: NettyFrameDecoder.java,
> > > NettyFrameEncoder.java, NettyServer.java and NettyTransceiver.java, in
> > > which
> > > Encoder/Decoder classes transform data structure between
> List<ByteBuffer>
> > > (need by Responder) and ChannelBuffer (need by Netty), Server class as
> a
> > > server and Transceiver as a client. The design is more similar with
> > > SocketServer and SocketTransceiver, so does the usage. i.e.
> > >
> > >        // server
> > >        Responder responder = new SpecificResponder(Mail.class, new
> > > MailImpl());
> > >        Server server = new NettyServer(responder, new
> > > InetSocketAddress(0));
> > >        Thread.sleep(1000); // waiting for server startup
> > >
> > >        // client
> > >        int serverPort = server.getPort();
> > >        Transceiver transceiver = new NettyTransceiver(new
> > > InetSocketAddress(serverPort));
> > >        Mail proxy = (Mail)SpecificRequestor.getClient(Mail.class,
> > > transceiver);
> > >
> > >        Message msg = new Message();
> > >        msg.to = new Utf8("wife");
> > >        msg.from = new Utf8("husband");
> > >        msg.body = new Utf8("I love you!");
> > >
> > >        try {
> > >            Utf8 result = proxy.send(msg);
> > >            System.out.println("Result: " + result);
> > >        } finally {
> > >            transceiver.close();
> > >            server.close();
> > >        }
> > >
> > > 2, your design has about 10 files because  you use more handlers in the
> > > pipeline and more top level classes such as client/server
> > PipelineFactory.
> > > The biggest difference is that your client and server class design is
> not
> > > similar with SocketTransceiver/SocketServer or
> HttpTransceiver/HttpServer
> > > pair. And the usage method is :
> > >
> > >        // server
> > >        netSocketAddress address = new InetSocketAddress(port);
> > >        AvroServer server = new AvroServer(address); // where is the
> > > Responder instance ?
> > >
> > >        // client
> > >        InetSocketAddress address = new InetSocketAddress(port);
> > >        AvroClient client = new AvroClient(address);
> > >        Message message = createMessage(to, from, body);
> > >        String response = client.dispatch(message); // not use the Proxy
> > > pattern
> > >        System.out.println("response: " + response);
> > >        client.dispose();
> > >
> > > In your design there is a problem that you create a specific Responder
> > > instance using specific protocol in AvroServerHandler which could not
> be
> > > reused in other circumstances.
> > >
> > > So, I think my design is more close to the Avro's way. How do you think
> > > about it? and anyone else?
> > >
> > > - harry
> > >
> > > On Fri, Jun 25, 2010 at 11:47 AM, James Todd <james.w.todd@gmail.com>
> > > wrote:
> > >
> > > > the latest/greatest patch against AVRO-405 is:
> > > >
> > https://issues.apache.org/jira/secure/attachment/12441447/AVRO-405.patch
> > > >
> > > > it's a merge of bo shin's and my work.
> > > >
> > > > there is more to do here, should be summarized in the comments iirc,
> > but
> > > it
> > > > would be great to get this initial spike done and build
> > > > on from that point.
> > > >
> > > > best,
> > > >
> > > > - james
> > > >
> > > > On Thu, Jun 24, 2010 at 8:04 PM, harry wang <coolwhy@gmail.com>
> wrote:
> > > >
> > > > > OK. But it seems that someone else has already made a netty-rpc
> > patch.
> > > I
> > > > > would like to see if my work could be merged into it.
> > > > >
> > > > > - harry
> > > > >
> > > > > On Fri, Jun 25, 2010 at 2:50 AM, Doug Cutting <cutting@apache.org>
> > > > wrote:
> > > > >
> > > > > > This would make a great contribution!
> > > > > >
> > > > > > Can you please attach it as a patch to an issue in Jira?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Doug
> > > > > >
> > > > > >
> > > > > > On 06/24/2010 11:29 AM, harry wang wrote:
> > > > > >
> > > > > >> hi, I have implemented the Avro RPC Server and Transceiver using
> > > > Netty.
> > > > > If
> > > > > >> anyone is interested in it, you can look at
> > > > > >> http://github.com/coolwhy/avro-rpc-on-netty. Any suggestion is
> > > > welcome.
> > > > > >> Thanks!
> > > > > >>
> > > > > >> - harry
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

--000325574cb2356e8b0489df5ad3--