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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > 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 > > > >> > > > >> > > > > > >
