Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client configuration for streaming connections #30

Closed
itaibenari opened this issue Oct 31, 2012 · 5 comments
Closed

Client configuration for streaming connections #30

itaibenari opened this issue Oct 31, 2012 · 5 comments

Comments

@itaibenari
Copy link

Currently if you create a streaming connection it defaults to timeout after 60000 ms. In order to override it you must pass a client which is configured to not timeout:

object StreamClient {
  import com.ning.http.client.{AsyncHttpClient, AsyncHttpClientConfig}
  import com.ning.http.client.providers.netty.NettyAsyncHttpProviderConfig

  lazy val client = new AsyncHttpClient(config)
  lazy val config = new AsyncHttpClientConfig.Builder()
      .setRequestTimeoutInMs(-1)
      .setAsyncHttpClientProviderConfig(
        new NettyAsyncHttpProviderConfig().addProperty(
          NettyAsyncHttpProviderConfig.BOSS_EXECUTOR_SERVICE, bossExecutor
        )
      ).build()
  lazy val bossExecutor =
      java.util.concurrent.Executors.newCachedThreadPool(DaemonThreads.factory)
}

Http(client = StreamClient.client)

It would be nice to make this setting more streamlined in a similar way to how promise timeout is set.
Unless there is an easier way I am not aware of that is...

@softprops
Copy link
Contributor

I feel like making the dispatch Defaults public would help a bit. Otherwise, those providing builders are going to have to resort to the same kind of copy and paste code

@itaibenari
Copy link
Author

Since "reboot" has built in support for streams it makes sense to me that it should be easier for new users to make use of this feature without resorting to investigate the source code of dispatch and API of async-http-client. Changing Defaults is a step in the right direction though.

@n8han
Copy link

n8han commented Oct 31, 2012

Geez guys, can't Dispatch keep anything private? :)

I didn't have time to come up with a great Defaults interface for 0.9.3 and needed some freedom to redo it in the future. There should really be a method on Http for building on the default configuration. I'll push some code here in a bit.

With 0.9.3 you'll have to live with some config boilerplate, but at least it's forwards-compatible config boilerplate!

@n8han
Copy link

n8han commented Oct 31, 2012

Also now that I'm aware of this issue I'm inclined to default to not having a request timeout. Any thoughts on the downsides of that?

@itaibenari
Copy link
Author

None in my eyes.

@n8han n8han closed this as completed in 3fefb2e Nov 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants