3 ms·

All great libraries, all a little different from each other. Scala provides a lot of flexibility for designing solutions. On top of that it's a relatively new l

All great libraries, all a little different from each other. Scala provides a lot of flexibility for designing solutions. On top of that it's a relatively new language with new open source projects appearing all the time, changing the landscape at an impressive rate. For instance, Smoke is built entirely on top of Akka 2.0, which was only released a few months ago but is an impressive step forward for parallelism on the JVM. Combine Scala's flexibility with the importance of HTTP to so many of us, I'm not surprised (nor disappointed) to see a lot of variety in this space. I hope we'll see even more of them as the language matures. We didn't see any of those libraries as an ideal solution to our problem so we built our own. If this solves a problem for you as well, I'd be happy to hear that. If not, I'd love to hear how you think it could be improved.

noelwelsh 14y ago
Well, I prefer a different mechanism for error handling. If you scroll down to "Error Handling" at http://noelwelsh.com/blueeyes/concurrency.html http://noelwelsh.com/blueeyes/concurrency.html you'll see my solution and justification for it. (FWIW, BlueEyes is based on Akka 2.0's Futures as well.)
- chrisdinn 14y ago
  Thanks for the link, that was a good read. Sounds like the concern is that when an error is raised inside an actor, the error is swallowed by that actor's thread. If you were waiting for it to respond you're end up with a mysterious timeout error and no idea where it came from. That's a good issue, one I definitely struggled with. Internally, we're addressing this problem by building our actors in such a way that they return a Status.Failure when an error is raised, using unit tests to ensure a response is always sent even when an error occurs. Typically, our responder functions are built from a number of Futures composed using the tools provided by Akka. This works well in some cases, when an error is raised early in a function composed from many Futures it gets passed right to the OnError handler to return an appropriate response. In the case where you get a mysterious timeout it can definitely make debugging difficult. Akka's excellent logging has saved us there many times. The goal was to lean on Akka whenever possible, adding elements to the Smoke DSL only when absolutely necessary. We've been able to make this work in some pretty non-trivial applications. Will that work for everyone? Hard to say. Your mileage may vary.

noelwelsh 14y ago

Well, I prefer a different mechanism for error handling. If you scroll down to "Error Handling" at http://noelwelsh.com/blueeyes/concurrency.html http://noelwelsh.com/blueeyes/concurrency.html you'll see my solution and justification for it. (FWIW, BlueEyes is based on Akka 2.0's Futures as well.)

chrisdinn 14y ago
Thanks for the link, that was a good read. Sounds like the concern is that when an error is raised inside an actor, the error is swallowed by that actor's thread. If you were waiting for it to respond you're end up with a mysterious timeout error and no idea where it came from. That's a good issue, one I definitely struggled with. Internally, we're addressing this problem by building our actors in such a way that they return a Status.Failure when an error is raised, using unit tests to ensure a response is always sent even when an error occurs. Typically, our responder functions are built from a number of Futures composed using the tools provided by Akka. This works well in some cases, when an error is raised early in a function composed from many Futures it gets passed right to the OnError handler to return an appropriate response. In the case where you get a mysterious timeout it can definitely make debugging difficult. Akka's excellent logging has saved us there many times. The goal was to lean on Akka whenever possible, adding elements to the Smoke DSL only when absolutely necessary. We've been able to make this work in some pretty non-trivial applications. Will that work for everyone? Hard to say. Your mileage may vary.