avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Todd (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-405) Netty-based Java RPC server
Date Mon, 28 Jun 2010 06:17:53 GMT

    [ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883038#action_12883038

James Todd commented on AVRO-405:

hey scott -

  i welcome feedback re AVRO-405.patch, please see above comments for associated context.

  remaining work, assuming the work thus far is viable/etc (i have received feedback from
several indicating it works as expected), includes:

    (resolve TODO) be adding a responder delegate interface that is invoked during request
handshake but before request processing

    use latest netty distribution (should be trivial)

    build alternative protocol specified by bruce

  i would appreciate a sync check/feedback for the current patch before proceeding. again,
there should be ample review context in the above associated comments and the patch proper.


- 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-coolwhy.patch, AVRO-405-for-review.patch, AVRO-405.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.

View raw message