[
https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854671#action_12854671
]
Bo Shi commented on AVRO-405:
-----------------------------
Hi James,
Some comments on a quick review of the current github link HEAD before you get
too far into your merge
These are mostly related to server-side, as I haven't been following async
client implementation at all.
* I'm warming up to chaining existing netty decoders as you have done in your
pipeline definition although I think we should characterize the performance
impact compared to implementing the decode/encode in one pass. Likely in
real-world RPC implementations the decode/encode step becomes a very small part
of the total computation performed per call, still though we can probably get
some gains for cheap here (in particular LengthFieldBasedFrameDecoder [1] does
way more than we need - maybe we just use a stripped down version - the
implementation is very simple).
* Taking the lead from existing client/server implementation in avro, our async
server should implement the org.apache.avro.ipc.Server interface and the client
should extend the org.apache.avro.ipc.Transceiver abstract class. Doing this,
you won't have to modify the unit test in my patch and it will enable one liner
switch to nonblocking rpc in projects like
http://github.com/phunt/avro-rpc-quickstart
* (minor) In the github repo, the package prototype.netty.avro is further
divided into three sub-packages. It seems to me that a simple flat package
structure is sufficient for this implementation (I don't forsee see the need to
support more than one binary protocol).
Todd L: Any word on when the streaming protocol will be finalized?
Regards,
Bo
[1]
http://grepcode.com/file/repository.jboss.com/maven2/org.jboss.netty/netty/3.1.0.BETA2/org/jboss/netty/handler/codec/frame/LengthFieldBasedFrameDecoder.java
> Netty-based Java RPC server
> ---------------------------
>
> Key: AVRO-405
> URL: https://issues.apache.org/jira/browse/AVRO-405
> Project: Avro
> Issue Type: New Feature
> Components: java
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Attachments: AVRO-405-for-review.patch, netty-avro.zip
>
>
> A nonblocking RPC server based on Netty should be more scalable than the
> current implementation.
> We should provide two mechanisms for interfacing the RPC server to the
> implementations:
> 1) "Blocking" RPC implementations run inside a worker threadpool.
> Implementators would not know that they're working in a non-blocking context.
> 2) "Event-driven" RPC implementations that receive requests and some kind of
> request context. They are responsible for eventually calling
> context.respond(response) or somesuch. This would allow more scalable
> interaction with downstream services.
> I propose we focus on (1) first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
