Dispatch 0.9.3 released

[Nathan Hamblen]

Retries, Http auto-shutdown, json4s, Http config, path appender correctness *and* completeness (finally)...

http://notes.implicit.ly/post/34495822045/dispatch-0-9-3

[Adam Shannon]

Reboot is a rewrite of the dispatch project. The current release is
the version 0.9.3. You'll probably have to re-think a bit on how to
best use dispatch. It's a lot more async in nature now.

On Mon, Oct 29, 2012 at 2:48 PM, Brian Maso <br...@blumenfeld-maso.com> wrote:
> What is the relationship between 0.9.3 and reboot? I'm ready to upgrade from
> 0.8.8 now, but I'm not sure which direction I should be going in.
>
> Brian Maso

--
Adam Shannon
Developer
University of Northern Iowa
Junior -- Computer Science B.S. & Mathematics
http://ashannon.us

[Doug Tangren]

On Sun, Oct 28, 2012 at 1:38 PM, Nathan Hamblen <nat...@technically.us> wrote:

Retries, Http auto-shutdown, json4s, Http config, path appender correctness *and* completeness (finally)...

http://notes.implicit.ly/post/34495822045/dispatch-0-9-3

Are there any changes in the last release that would break when using a custom async client builder?

I just refactored some code to use the new Http case class copy interface ( note I'm incorporating the extra netty provider option introduced in the last release )

https://github.com/softprops/distress/blob/master/src/main/scala/http.scala#L36-58 

I previously needed to override the underlying client so I could control concurrency when running n number of requests. This used to work but now when I run my app I get a ton of java.util.concurrent.RejectedExecutionException errors ( https://gist.github.com/3981689 )

Was there any change that would break usage when using a custom client as listed above that I should expect?

Thanks.

[Nathan Hamblen]

On 10/30/2012 01:30 PM, Doug Tangren wrote:

On Sun, Oct 28, 2012 at 1:38 PM, Nathan Hamblen <nat...@technically.us> wrote:

Retries, Http auto-shutdown, json4s, Http config, path appender correctness *and* completeness (finally)...

http://notes.implicit.ly/post/34495822045/dispatch-0-9-3

Are there any changes in the last release that would break when using a custom async client builder?

Yep, check notes.implicit.ly.

Nathan

[Doug Tangren]

Arg! I caught it on the second pass. "The Http case class refactor is likely to break code that does any significant customization of its Http instance" I do like the new interface and the fact that I can pass in my own client (async http client builder is very customizable) but I'm not sure which client options are now off limits. I'm only using two or three and I immediately was thrown these exceptions. I'll check out the new factory methods provided to see if the can accomplish what the underlying builder options I'm using did without changing behavior.

For future reference, is there a white list for what options can be configured on the client and a black list for those that will break? I'll try and avoid those in the future.

[Nathan Hamblen]

On 10/30/2012 06:43 PM, Doug Tangren wrote:

On Tue, Oct 30, 2012 at 3:09 PM, Nathan Hamblen <nat...@technically.us> wrote:

On 10/30/2012 01:30 PM, Doug Tangren wrote:

On Sun, Oct 28, 2012 at 1:38 PM, Nathan Hamblen <nat...@technically.us> wrote:

Retries, Http auto-shutdown, json4s, Http config, path appender correctness *and* completeness (finally)...

http://notes.implicit.ly/post/34495822045/dispatch-0-9-3

Are there any changes in the last release that would break when using a custom async client builder?

Yep, check notes.implicit.ly.

Arg! I caught it on the second pass. "The Http case class refactor is likely to break code that does any significant customization of its Http instance" I do like the new interface and the fact that I can pass in my own client (async http client builder is very customizable) but I'm not sure which client options are now off limits. I'm only using two or three and I immediately was thrown these exceptions.

Hm, I wasn't expecting any runtime exceptions. Is that Client.of def perhaps called more than once? Generally you should only use one Http instance.

[Doug Tangren]

It's called once per run and shared between many requests.

I factored in some of the new changes but am stuck on how to define a Success instance for a Promise of type Promise[Response] (I'm using an identity function handler) Below is a snippet from my code with some extra inline comments sprinkled in for context

     

      // a noop handler that just tracks timing of a handled requests

       // https://github.com/softprops/distress/blob/master/src/main/scala/http.scala#L14-18

      val ts = new Timestamp 

      // I used to use underlying clients retry handling for failed requests

      // the retry.Directly call below doesn't compile because the handler 

      // uses the identity function handler which 

      // is a Promise[Response] Not Promise[Either[..,..]] or Promise[Option[...]]

      // so there are no implicit param for its type defined.

      // the underlying client defined errors for its retry interface as network errors 

      // https://github.com/AsyncHttpClient/async-http-client/blob/master/api/src/main/java/com/ning/http/client/AsyncHttpClientConfig.java#L906-915

      // how would can I handle these same kind of network error retries using the new dispatch retry interface?

      retry.Directly(3)(client(req > ts) 

        .onComplete({

          case _ => // aggregate completion

        })

        .onSuccess({

          case _ => // aggregate success

        })

        .onFailure({

          case _ => // aggregate failure

        }))