You can clone with
HTTPS or Subversion.
I wonder if it's possible to have a version which supports persistent connections like net-http-persistent.
For that, it would probably be better to have a connection object that is not memoized per channel but per end-point. Maybe introduce a new Pusher::Client that can be derived by different http client implementations and can be used by the Pusher::Channel. That would also avoid having inline requires in Channel#trigger.
I completely agree that using keep-alive connections would be great.
Thanks for the pointer to net-http-persistent. I've previously tried some experiments with em-http-request but had a few issues the the handling of dead connections. Hoping to get back on the case with this soon.
I have some refactorings in progress that slightly separate the http connections from the actual api methods (to support multiple api methods), so it's probably worth getting that merged in first or it will be conflict heaven :)
Could this actually be better implemented with the Pipe? (when it's out of alpha / beta)
While yes persistent http-connections would be good, if you're sending that many events, then surely there would be even greater benefit from using just one persistent websocket connection?
There is also net-http-pipeline but I don't vouch for the quality of the client. Tell me when you are have done the merge I might take a look at both.
At the moment, we are using right_http_connection but besides the name, it does nothing right. It hijacks Net::HTTP but also randomly throws NoMethodError, TypeError and friends (which happen when the connection is lost). In the end, I wrapped the Pusher::Channel#trigger! with a retryable to make sure the messages are passing trough.
@zimbatm I've merged the changes I was talking about which refactors the HTTP handling into Pusher::Request. Plenty more improvements that can be made to this, I just teased it apart from the Channel object, but if you do fancy giving pipelining a whirl you're very much welcome :)
Finally available, using the httpclient gem (not for em-http-request at this stage).
Having looked at all the options, the major advantages and reasons for choosing httpclient were that:
Ran into issues due to httpclient today (consistent timeout error on every use). Would have much rather used faraday or similar.