[
https://issues.apache.org/jira/browse/THRIFT-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Sanford updated THRIFT-146:
---------------------------------
Attachment: 0015-Added-EventMachine-tutorial-example.patch
0014-Eventmachine-spec-cleanup-for-ruby-1.8.patch
0013-Added-timeout-option-to-eventmachine-transport.patch
0012-Eventmachine-triggers-errback-on-connect-errors.patch
0011-Added-eventmachine-test-for-void-functions.patch
0010-Added-test-for-oneway-functions-with-eventmachine.patch
0009-Added-an-asnyc-test-for-EventMachine.patch
0008-Initial-event-machine-test.patch
0007-Generate-eventmachine-bindings-for-tests.patch
0006-Added-eventmachine-as-a-dev-dependency.patch
0005-rb-eventmachine-can-have-a-separate-namespace-than-r.patch
0004-Added-EventMachineTransport-class.patch
0003-Added-ruby-eventmachine-compatible-client-code.patch
0002-Added-rb-eventmachine-option-to-the-compiler.patch
0001-Ruby-client-increments-sequence-ids.patch
I've attached a patch series implementing an EventMachine client for thrift.
The work is based on the Twisted and NodeJS implementations.
There is a new compiler namespace rb:eventmachine that will generate the em
specific bindings.
All of the thrift calls will return an EventMachine::Deferrable object. Once
the service has responded, the deferrable's .callback function will be executed
with the resulting value if there is one. Here's a sample:
{code}
require 'eventmachine'
require 'gen-rb.eventmachine/example_client'
require 'thrift/transport/event_machine_transport'
EM.run do
connection = Thrift::EventMachineTransport.connect(ExampleClient, host, port)
connection.errback { puts "Could not connect to server"; EM.stop_event_loop; }
connection.callback do |client|
client.rpc_method_a(value).callback {|result| puts "got result #{result}"; }
end
end
{code}
There is a real example in tutorial/rb/RubyClientEventMachine.rb. There are
also roundtrip tests in event_machine_client_spec.rb that provide in depth
examples.
Note that 'EventMachine' is a development_dependency in the gemspec instead of
a runtime dependency. Since most existing projects do not use EventMachine it
probably doesn't make sense to force them to install the EM gem. If you want to
use this you will need to require eventmachine yourself. You will also need to
require 'thrift/transport/event_machine_transport' as it references
EventMachine classes so it is not required by default in thrift.rb.
> Make Thrift EventMachine Compatible
> -----------------------------------
>
> Key: THRIFT-146
> URL: https://issues.apache.org/jira/browse/THRIFT-146
> Project: Thrift
> Issue Type: Improvement
> Components: Ruby - Library
> Environment: Ruby and EventMachine
> Reporter: Ben Taitelbaum
> Priority: Trivial
> Attachments: 0001-Ruby-client-increments-sequence-ids.patch,
> 0002-Added-rb-eventmachine-option-to-the-compiler.patch,
> 0003-Added-ruby-eventmachine-compatible-client-code.patch,
> 0004-Added-EventMachineTransport-class.patch,
> 0005-rb-eventmachine-can-have-a-separate-namespace-than-r.patch,
> 0006-Added-eventmachine-as-a-dev-dependency.patch,
> 0007-Generate-eventmachine-bindings-for-tests.patch,
> 0008-Initial-event-machine-test.patch,
> 0009-Added-an-asnyc-test-for-EventMachine.patch,
> 0010-Added-test-for-oneway-functions-with-eventmachine.patch,
> 0011-Added-eventmachine-test-for-void-functions.patch,
> 0012-Eventmachine-triggers-errback-on-connect-errors.patch,
> 0013-Added-timeout-option-to-eventmachine-transport.patch,
> 0014-Eventmachine-spec-cleanup-for-ruby-1.8.patch,
> 0015-Added-EventMachine-tutorial-example.patch, thrift_eventmachine.rb
>
>
> I wrote a prototype EventMachine client/server for Thrift (BinaryProtocol),
> and while it's not fully functional, the results are so promising, that I
> think it would be worth it to either include an EM client/server with the
> thrift distribution, or at least rework the libraries so that they can
> support EM without having to copy/paste all the code I did.
> I'm attaching my prototype as an example. It requires the eventmachine and
> statemachine gems. It's wired to support a simple echo service. It's a little
> confusing in that I reused the same statemachine for both client and server,
> doesn't handle exceptions, and has a bug where it'll handle all requests from
> one client before handling requests from another, but hey, it's a prototype.
> EM uses very different semantics from typical client/server, and this
> presents difficulty wiring it to the current thrift protocols. For example,
> while currently, you can call call prot.read(n) to read n bytes off of a
> stream, or wait until they're available, with EM, if n bytes aren't
> available, you simply don't handle the call yet. I handled this by trying to
> read as many bytes as need be, and keeping track of how much to backup in the
> stream, ultimately only transitioning to the next state in the statemachine
> if we were able to read all the bytes needed. This actually works fairly
> well, but it would be better if we had a byte count at each step so we could
> tell right away if we had enough data.
> The use of EM allows for new asynchronous semantics for thrift calls, in that
> the client returns right away from a call, and its callback is called when a
> result (or exception) is available. Backwards compatibility could still be
> achieved by blocking on a call, but at least in my experience, in most of the
> cases having callbacks would be a huge optimization. There are some cases
> where I do want to either ensure that calls happen sequentially, or are at
> least handled in the same order.
> These are the changes I believe would have to be made in order to support an
> EM thrift connection:
> 1. syntax to indicate that certain methods can be called asynchronously with
> callbacks. Since async is already a reserved keyword, and is changing to
> noreturn, what about using this?
> 2. I would propose moving all reading and writing to the same class. So
> instead of having ThriftStruct#read, we would have Protocol#read_struct. It
> seems out of place to me to have a model handle its own reading / writing.
> 3. support for byte counts in the protocols. It would be helpful to have a
> clear way to get the number of bytes that must be read to retrieve message
> headers, arguments, and results. Alternatively, the protocols could support
> read_or_backup semantics, but as you can see in my prototype, this can get
> messy.
> Please let me know what you think about this proposal, and the possibility of
> using EventMachine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
