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
> On Sunday, October 28, 2012 10:38:42 AM UTC-7, n8han wrote:
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 )
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?
> 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. 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.
> 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.
>> 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.
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
// 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.
