Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Persistent connections ? #13

Closed
zimbatm opened this Issue · 6 comments

4 participants

@zimbatm
Owner

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.

@mloughran

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 :)

@miksago

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?

@zimbatm
Owner

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.

@mloughran

@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 :)

@mloughran

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:

  • Sessions are reused across threads (this is not the case for excon and net-http-persistent for example). This is a big deal in rails apps for example where each incoming http connection spawns a new thread.
  • It has built in support for making async requests using threads with the same sensible session management and reuse. This allows us to support the _async methods even when eventmachine is not available.
@mloughran mloughran closed this
@jhawthorn

:-1: Ran into issues due to httpclient today (consistent timeout error on every use). Would have much rather used faraday or similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.