Thrift
  1. Thrift
  2. THRIFT-1

Fully-asychronous client and server

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      All

      Description

      All Thrift servers currently require a thread to be tied up for every outstanding request being serviced.

      In addition, all clients have the same requirement, but workarounds are easier.

      This is also the first JIRA issue in the Thrift project.

        Activity

        Hide
        Bryan Duxbury added a comment -

        We've already got an asynchronous server for Java. I'd be interested to think about async clients, though.

        Show
        Bryan Duxbury added a comment - We've already got an asynchronous server for Java. I'd be interested to think about async clients, though.
        Hide
        Esteve Fernandez added a comment -

        Bryan: are you using a specific library (a la Apache MINA) or is it just pure NIO + Listeners? I worked on the client part using MINA, returning a DefaultReadFuture (http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/DefaultReadFuture.html) on every call.

        It's basically the same approach as THRIFT-148: don't return the actual value, but a future/deferred/promise and attach callbacks/listeners that will be fired when the return value becomes available.

        Show
        Esteve Fernandez added a comment - Bryan: are you using a specific library (a la Apache MINA) or is it just pure NIO + Listeners? I worked on the client part using MINA, returning a DefaultReadFuture ( http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/DefaultReadFuture.html ) on every call. It's basically the same approach as THRIFT-148 : don't return the actual value, but a future/deferred/promise and attach callbacks/listeners that will be fired when the return value becomes available.
        Hide
        Alexander Shigin added a comment -

        I've got async client for python with asyncore. And I'm trying to make C++ nonblocking server a full async.

        Show
        Alexander Shigin added a comment - I've got async client for python with asyncore. And I'm trying to make C++ nonblocking server a full async.
        Hide
        Esteve Fernandez added a comment -

        David: I think it would be better if this ticket depended on several subtasks, one for each language. What do you think?

        Show
        Esteve Fernandez added a comment - David: I think it would be better if this ticket depended on several subtasks, one for each language. What do you think?
        Hide
        David Jeske added a comment - - edited

        To clarify, it looks like Thrift has a non-blocking I/O implementation in most stub-languages, but the only language that supports an async handler interface for client or server is Python-Twisted. (an async handler interface requires return values provided via callback, so the handler can let go of the request-thread without producing a result)

        Eric Bernhardsson did some work on a C++ async handler interface which hasn't been incorporated yet. (it's listed in subtasks above, but here it is again)

        https://issues.apache.org/jira/browse/THRIFT-579

        One route for Java-async-handlers is to build on Netty, a twisted-like event-driven framework for Java. Another route is to avoid dependencies on a framework and refactor the java-core to handle async return results and add the ability for the stubs to generate 'return result callbacks' that decouple the handler-thread from the return result.

        Show
        David Jeske added a comment - - edited To clarify, it looks like Thrift has a non-blocking I/O implementation in most stub-languages, but the only language that supports an async handler interface for client or server is Python-Twisted. (an async handler interface requires return values provided via callback, so the handler can let go of the request-thread without producing a result) Eric Bernhardsson did some work on a C++ async handler interface which hasn't been incorporated yet. (it's listed in subtasks above, but here it is again) https://issues.apache.org/jira/browse/THRIFT-579 One route for Java-async-handlers is to build on Netty, a twisted-like event-driven framework for Java. Another route is to avoid dependencies on a framework and refactor the java-core to handle async return results and add the ability for the stubs to generate 'return result callbacks' that decouple the handler-thread from the return result.

          People

          • Assignee:
            Unassigned
            Reporter:
            David Reiss
          • Votes:
            7 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 168h
              168h
              Remaining:
              Remaining Estimate - 168h
              168h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development