Offer non-blocking client API for cloudhopper SMPP

[RichardBradley]

Hi,

We're using cloudhopper-smpp in an application using Akka Actors in Scala and would like to avoid blocking threads.

While the underlying Netty IO used by cloudhopper is non-blocking, many cloudhopper-smpp operations will block during the method calls.

In particular, the following operations are currently blocking:

• Binding blocks both on establishing the network connection and the initial bind request/response pair.
• Unbinding blocks on the unbind request/response pair and unbinding the connection
• Sending a request PDU blocks on a free window slot and to send the request over the connection
• Sending a response PDU blocks on sending the response over the connection

It would be nice if there were a non-blocking API exposed for applications which would rather not block threads.

I think the code changes required should be fairly simple and isolated to the relevant parts of cloudhopper-smpp. You could create non-blocking versions of the above methods and keep the current blocking API in place by awaiting those results as they do currently.

There are two current types of blocking used: 1) waiting for free window slots (see twitter/cloudhopper-commons#5 ) and 2) calling await on Netty future objects. The former will need some work as per the linked issue, but the latter has asynchronous callback support already. The implementation code for these operations looks to be in DefaultSmppClient and DefaultSmppSession.

Thanks,

Rich

[jjlauer]

If you treat SMPP binds as long-lived resources, why not "prepare" them before using them asynchronously? I can see the value in a totally non-blocking send PDU method, but until a session is bound its not useful. That's just my two cents -- happy to understand that a bit more.

Feel free to submit a PR to implement -- maybe you could start with the request PDU part before bind/unbind. Here are things to keep in mind:

• We have an open Netty4 beta branch and we are trying to keep Netty3 and Netty4 support in-sync -- so design any changes with that in mind.
• Error handling & method naming will be interesting. I'll be curious what you come up with.
• Make sure to include unit tests

[RichardBradley]

Sure, I agree that the binding / unbinding being blocking is much less important than the send-PDU. We can block a few threads on startup without much harm. However, having the send-PDU be possibly-blocking is a big issue for an Actor based system.

(I saw a bug recently in one of our systems where a library was mostly non-blocking, except when overloaded and it would block waiting for a free connection slot. We hadn't noticed and hadn't given it its own thread pool. This caused havoc when the machine was overloaded, as everything stops if the Actor worker pool is blocked, including responding to new socket requests and even logging.)

We may have some time to prepare a PR for this, but it won't be for a little while. Thanks for the heads up.