Actors are not always the best solution

[bearophile]

This is a quotation from the "Twitter on Scala" by Bill Venners, April 3, 2009:
http://www.artima.com/scalazine/articles/twitter_on_scala.html

>So it is a specialized system. We’ve built it in Scala wrapping Jetty, and initially we had a number of actors inside the system: one to pull messages off of our internal messaging queue, and a number of other actors that represented clients. And over time as we ran more and more system tests on it, we found that actors weren’t necessarily the ideal concurrency model for all parts of that system. Some parts of the concurrency model of that system are still actor based. For example, it uses a memcache library that Robey wrote, which is actor based. But for other parts we’ve just gone back to a traditional Java threading model. The engineer working on that, John Kalucki, just found it was a little bit easier to test, a bit more predictable. The nice thing was, it took minutes to switch code that was actor based over to something thread based. It was a couple of search and replaces. So it’s not so bad if actors fail you for whatever reason.<

Bye,
bearophile