[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avro-dev
Subject:    [jira] Updated: (AVRO-405) Netty-based Java RPC server
From:       "harry wang (JIRA)" <jira () apache ! org>
Date:       2010-06-29 4:52:54
Message-ID: 27811493.106461277787174386.JavaMail.jira () thor
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/AVRO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

harry wang updated AVRO-405:
----------------------------

    Attachment: AVRO-405-coolwhy-new.patch

My new patch to make the NettyTransceiver look better. The transport protocol has \
been changed to support some async call feature in the client side.

> 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-new.patch, AVRO-405-coolwhy.patch, \
> 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.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]