Provide non-blocking I/O functionality to the Ruby APIs

Details

Description

Provide functionality that overcomes the limitation of the Ruby global interpreter. Prevent the Ruby VM from become become unresponsive when a blocking I/O call is made so that other Ruby threads can continue to execute while the I/O continues.

Activity

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/2828/
-----------------------------------------------------------

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.

There's a whole lot of code here and I don't understand it well enough to actually review it - below are some random comments that occurred to me whilst reading through.

I would say that the amount of code seems disproportionate to the actual functionality, but that is clearly subjective. However the code really isn't well enough explained to be able to understand what the pieces do and how they relate.

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.

> This seems like a serious problem, perhaps it needs to be addressed before putting this change to trunk?

The underlying implementation, when executing the tests, don't seem to quickly response when there are messages waiting. I'm not sure if it's in how the Ruby VM interacts with the external code or not, or if it's something else entirely.

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.

> Why the dead code in a comment? If it needs to be there say why. If not delete it, but tell me why you getDeadline and then ignore the answer.

Darryl Pierce wrote:

These are elements brought over from the code I copied from Gordon's patch set. I'll let him comment on them.

The commenting out was not from me. My initial sketch of the added API and implementation (https://reviews.apache.org/r/1687) does however have some redundant calls. It looks like they were part of the early evolution that didn't get removed. The solution is to remove the lines entirely not to comment the return value out.

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/2828/
-----------------------------------------------------------

This update completely strips out the Tracker codebase and provides the non-blocking functionality separately.

Summary
-------

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:https://reviews.apache.org/r/2828/
-----------------------------------------------------------

This first pass has full integration of the Tracker type with the Ruby bindings to provide a non-blocking means for responding to incoming messages.

After a Receiver is created, a call to Qpid::Messaging.receive will wait for the next message to become available on it. When one is received, a provided lambda function is invoked and the receiver passed to it. The message can then be retrieved, acknowledged, etc.