[
https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Todd updated AVRO-405:
----------------------------
Attachment: AVRO-405.patch
deps:
patch is relative to the [avro]/lang/java directory (ie cd [avro]/lang/java;
patch -p0 < AVRO-405.patch)
requires netty 3.1.5GA
workaround: download netty-3.1.5.GA.jar and copy it to the build/lib dir
(note: would be optimal to update ivy.xml)
addressed:
flattened package (see org.apache.avro.ipc.netty, opted to not co-populate
o.a.a.ipc at this time)
included ref/proto code (see org.apache.avro.ipc.netty.prototype)
o.a.a.ipc.netty.NettyServer implements o.a.a.ipc.Server
o.a.a.ipc.netty.NettyClient does *not* extend o.a.a.ipc.Transceiver
note: .o.a.a.ipc.netty.AvroClientHandler includes an internal
o.a.a.ipc.Transceiver for netty/avro delegation
we should be able to reconstruct the tests accordingly
opted to continue to use/leverage/delegate-to netty classes
note: there should be upside in having the netty code look as netty-native
as possible and optimizations should
perhaps be considered downstream a bit, eg once we move past the
current impl of accumulating ByteBuffer
issues/todo:
implement requestor/responder factory (eg via post handshake factory, etc)
references to the Mail/Message prototype code (borrowed from
avro-rpc-quickstart) persist until we can introspect
the outbound/inbound message and make the relevant instantiations (see
above issue)
construct/support/migrate tests
> 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: James Todd
> Attachments: AVRO-405-for-review.patch, AVRO-405.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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
