You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2010/02/05 23:46:27 UTC
[jira] Created: (AVRO-405) Netty-based Java RPC server
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
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.
Re: [jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by James Todd <ja...@gmail.com>.
I have been working through this as well, code can be found at:
http://github.com/jwtodd/netty-avro
would love to collaborate.
- james
On Mon, Apr 5, 2010 at 12:03 AM, Bo Shi (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853324#action_12853324]
>
> Bo Shi commented on AVRO-405:
> -----------------------------
>
> Anyone working on this? I had a bit of free time this weekend to go
> through the avro and netty tutorials and threw together something that might
> fit the bill. The implementation is mostly plumbing; I put together frame
> encoding and decoding a handler that wraps a Responder instance. Would
> welcome any comments.
>
> > 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
> >
> >
> > 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.
>
>
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854682#action_12854682 ]
James Todd commented on AVRO-405:
---------------------------------
great points bo.
i took the approach of the protobuf codecs as the baseline and opted to not dig into the backing pipeline impl details. put another way, striving to "make it work" followed by "make it work right and make it work fast." definitely cut some corners. i would expect the netty impls to be efficient, though. on the other hand streamlining is not a bad thing.
thx for the test heads up! that's definitely a good one to work in.
yeah, likely over refactored the packages a bit. did that as a part of componentizing the impl given we are evaluating using this code inhouse. flattening things out is likely needed.
i did leave a note on #netty for trustin to given him a heads up, see if the codec part of this work should/could reside w/ netty/etc.
- james
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843703#action_12843703 ]
Doug Cutting commented on AVRO-405:
-----------------------------------
Ning's posted an async Java HTTP client that might be useful for Avro.
http://code.ning.com/2010/03/introducing-nings-asynchronous-http-client-library/
> 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
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853417#action_12853417 ]
James Todd commented on AVRO-405:
---------------------------------
hi bo -
i have started piecing some some of this together and have placed the prototype code on github:
http://github.com/jwtodd/netty-avro
note: the project is sparse but does work to a degree
i would love to collaborate on this work.
- james
> 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
>
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855811#action_12855811 ]
James Todd commented on AVRO-405:
---------------------------------
i'll grab this one as we work through the initial blocking netty patch.
> 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, 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
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830357#action_12830357 ]
Todd Lipcon commented on AVRO-405:
----------------------------------
I'd like to do the protocol self-described as avro records. I think Matt Massie has some work on this somewhere - do we have an open JIRA for non-HTTP RPC?
Also, SASL support is a strong requirement for this to be used in Hadoop.
> 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
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Bo Shi (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855834#action_12855834 ]
James Todd commented on AVRO-405:
---------------------------------
hey bo shi, todd -
attached is a first cut at merging our patches along with the associated notes (eg assumptions, addressed issues, todo issues, etc).
i feel pretty good with this patch noting that there are a few open issues, namely we need to refactor out the explicit avro instance invocations
for Mail/Message via request/responder post handshake factory delegation, something i can likely start to chew on should this patch look ok.
hth,
- james
> 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
[jira] Updated: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Scott Carey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843710#action_12843710 ]
Scott Carey commented on AVRO-405:
----------------------------------
Don't forget Apache HTTP Components:
http://hc.apache.org/
This is the evolution of the old Apache Commons HttpClient. HTTP Components adds server side components and asynchronous I/O capability.
My experience with the old HttpClient was that it was significantly better performing and robust than the built-in sun java http client. Under high load with a lot of concurrent connections, there was a big (50% to 100%) difference.
> 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
>
> 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.
[jira] Assigned: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Todd reassigned AVRO-405:
-------------------------------
Assignee: James Todd
> 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, 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
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830345#action_12830345 ]
ryan rawson commented on AVRO-405:
----------------------------------
I am interested in this, both needing it and working on it as well. Netty seems like a great framework for dealing with these.
What protocol are you thinking about?
> 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
>
> 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.
[jira] Updated: (AVRO-405) Netty-based Java RPC server
Posted by "Bo Shi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bo Shi updated AVRO-405:
------------------------
Attachment: AVRO-405-for-review.patch
netty-based socket rpc implementation
> 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
>
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854589#action_12854589 ]
James Todd commented on AVRO-405:
---------------------------------
aim to merge patches and publish for review by this coming weekend
> 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.
[jira] Assigned: (AVRO-405) Netty-based Java RPC server
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reassigned AVRO-405:
--------------------------------
Assignee: (was: Todd Lipcon)
Assigning to unassigned since I can't seem to assign to either of you two :)
Regrading the streaming protocol, I don't think anyone is currently actively working on it -- other things have eclipsed it on the great priority queue :). If either of you wanted to submit a proposal that would be great!
> 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
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Bo Shi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853324#action_12853324 ]
Bo Shi commented on AVRO-405:
-----------------------------
Anyone working on this? I had a bit of free time this weekend to go through the avro and netty tutorials and threw together something that might fit the bill. The implementation is mostly plumbing; I put together frame encoding and decoding a handler that wraps a Responder instance. Would welcome any comments.
> 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
>
>
> 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.
[jira] Updated: (AVRO-405) Netty-based Java RPC server
Posted by "James Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Todd updated AVRO-405:
----------------------------
Attachment: netty-avro.zip
attached is zip file that contains all of the netty/avro patch files as found in http://github.com/jwtodd/netty-avro minus the (large) libs/* files
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830344#action_12830344 ]
Todd Lipcon commented on AVRO-405:
----------------------------------
I think the server type 1 above could become the default Java RPC server implementation. It has the nice scalability properties of being able to handle a lot of concurrent connections, and as long as the RPC handler isn't doing further downstream RPCs, it shouldn't be much worse than #2.
> 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
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853327#action_12853327 ]
Todd Lipcon commented on AVRO-405:
----------------------------------
Nice, Bo! I was planning on working on this but haven't had a chance to yet, so feel free to grab it. I'll try to take a look at your patch early this week.
> 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
>
>
> 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.
[jira] Commented: (AVRO-405) Netty-based Java RPC server
Posted by "Bo Shi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853412#action_12853412 ]
Bo Shi commented on AVRO-405:
-----------------------------
Thanks Todd; I am going to try to post an update within the next couple of days as (1) needs a bit of a re-org into multiple files instead of one monolithic source file and (b) the frame decoder needs some hardening against random/invalid/malicious input (e.g. AVRO-391 and THRIFT-601). Hopefully the async server will be less susceptible to memory-related issues.
> 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
>
>
> 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.