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.

        Issue Links

          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:
              4 Vote for this issue
              Watchers:
              5 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