Hi Kane,
Exploring the different options, one limitation that I can see is that > ClusterPoolRouter requires the class of the actor that's going to be > remotely deployed to the cluster to be *present on the class path of the > router. *That is, if our front-ends are to create a worker on a remote > machine to handle a request, the class for that router must be in the JAR > on the front-end machine. *Please correct me if I'm mistaken here.* > In my experience this is true. In my activator template <http://typesafe.com/activator/template/play-akka-cluster-sample> I used the same pattern you describe, building an *API* package that contains all the messages in order to distribute the classes over all services. However this means that your spray-frontend has dependencies to *all *API packages. This could get messy if you have a lot of small services (versioning, backwards compatibility, etc.) I'm really interested in other user suggestions :) cheers, Muki -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
