I have an application utilizing Spray, Akka, and Scala. The current unit testing is done via Scala Test. The application uses Spray routing to determine and parse some rudimentary data on web requests then passes it to an actor to do the required actions. For Spray we use a custom initialization class that inherits from spray.servlet.Initializer which configures and starts each of the actors. Part of those actions are to call out to some 7 or 8 other web services. Each has an actor to handle the communications with their respective services. So, we do a bunch of logic in the main actor which delegates the communication to other actors and at the end it processes all of the returned data in addition to it's own work along the way.
I would like to test the system as a whole using Scala Test and Akka Testkit using Testkit to substitute the communication actors to return suitable test data.
The question is two part.
What is the better approach to testing? I could use Scala Testkit to make requests through the Spray routing service via Spray Testkit. The alternative is, since the main actor takes the routing service results via a case class, is to just to directly pass the message to that actor skipping the routing service. Both have their merits. I however do find the documentation scant on Spray testkit. How would one sub the actors via Akka Testkit when there is initialization logic for those actors in spray.servlet.Initializer?
The second is how does one set up a more complex actor system via Akka Testkit. The documentation mentions this is possible but is far from expressive on exactly how one would do that. I have the routing service which is an actor that talks to another actor that is the bulk of business logic but then talks to several other actors. Are these communication actors considered "Child" actors in reference to the Akka Testkit documentation? Is there a project that demonstrates best practices in testing a rich Akka actor system as a whole?
My instincts in this case are to have a Spray Testkit based set of tests to test our routing system. Then, have a set of tests that send our data case class to the master actor with mocked comm actors behind it and verify we get the correct response back from the master actor.
I usually create tests for each layer of my application. Also, i mock the other layer when i'm testing the current layer. If i'm testing business i would mock the DAOs, if i'm testing spray routes i mock the business object(that is used by my spray routes).
I always try to start creating tests before the main program when i'm working with Actors and Spray, it helps in how should be my application architecture. Many times i need to refactor my class to use dependency injection or do not set the val in the current class/trait, so i can mock the vals.
Related
I'm new to both Play framework and Akka Toolkit.
We are trying to build an orchestration layer between the web client and microservices using Play.
So basically for every request from the client, Play has to do a WS call and return the JSON (as well as cache it).
Now when doing the WS call, we can use Play Async APIs or use Akka actors.
Does one of these options outweigh the other anyway?
Is there any recommendation on when one should venture into using Akka actors along with Play compared to directly using Play Async APIs?
In Akka, main notion as an actor, which is an object with memory to keep state. Sequential operations to that state are serialized by the system and cannot interfere. In Java8 promise/futures, main notion is asynchronous method call, and if different methods belong to the same object, it is user's responsibility to provide serial access - which is not easy and can be error prone.
Then, using futures implies creation of a Future object for each separate operation, which can be considered as overhead if the operations are fine-grained.
On the other hand, CompletableFuture has means to combine several events into one like allOf(), which has no direct analogue in Akka.
My application has an API using SprayCan. In the application, any blocking code has a separate dispatcher for each specific resource.
Is it necessary to protect the API service from being blocked by the application by configuring it with it's own Dispatcher too?
Also is it common practice to use a Router for an API service to handle a larger capacity of requests?
class MyService extends Actor with HttpService {...}
val service = system.actorOf(MyService.props(...).withDispatcher(???))
Is it necessary to protect the API service from being blocked by the
application by configuring it with it's own Dispatcher too?
Usually not necessary. Check reference.conf that comes as default config with Spray to see if that dispatcher will satisfy your needs. If not, provide a custom one.
Also is it common practice to use a Router for an API service to
handle a larger capacity of requests?
Usually requests are handed off to another Actor to unblock the route or ran as Future (possibly on a separate thread pool). See all available options here: How does spray.routing.HttpService dispatch requests?.
Finally, you should not block in the route handler because it will block your service. From your description it sounds like your blocking code runs in a Future or similar. As long as it does not make route handler wait for result/block it's fine.
I'm reading http://danielwestheide.com/blog/2013/02/27/the-neophytes-guide-to-scala-part-14-the-actor-approach-to-concurrency.html and in it, is declared :
"Sometimes, sending an actor a message and expecting a message in
return at some later time isn’t an option – the most common place
where this is the case is in components that need to interface with
actors, but are not actors themselves. Living outside of the actor
world, they cannot receive messages.
For situations such as these, there is Akka’s ask support, which
provides some sort of bridge between actor-based and future-based
concurrency. "
When does this situation apply, ie when to use Akka ask support ?
I'm using akka to create Actor requests that in turn create web service requests so I think this is a use case as I may not get a valid web service response in appropriate time frame. Also web service requests do not live in the Akka world. Am I correct in my reasoning ? What are the real world example where I should ask instead of tell ?
I have a back-end Scala application that needs to integrate with RabbitMQ. The back-end Scala app executes long running tasks asynchronously. Messages to execute the tasks are queued into RabbitMQ by a web client. The back-end application then consumes each of these messages, executing the corresponding long-running tasks.
Should Scala app directly consume the message from RabbitMQ and simply have the corresponding tasks be processed using Futures? Or is it better to use Akka Actors to receive these messages from RabbitMQ, and then execute the long-running tasks?
What are the pro's and con's of each approach?
Futures sound like a simpler approach for your use case combined with the RabbitMQ Java client.
My model for choosing actors v. futures is: prefer futures, switching to actors when I feel I have a good use case for them (see Good use case for Akka for some examples). For example, if you were trying to divide-and-conquer the batch workloads (as the linked answer states), actors may serve your purposes well.
Use the RabbitMQ Java examples below as a starting point, modifying to do work in futures so that the thread polling the work queue is not blocked. I included links to both work queue and RPC examples in case you need to return some response (RabbitMQ is good at this case as it has a concept of correlationId built in).
Java RabbitMQ examples:
Work Queues
Remote procedure call (RPC)
I need to implement various kind of topologies in AKKA actor model system
like Line,mesh etc. Are there in built libraries for various kind of topologies
in AKKA? If not how can I build such topologies? Also, how do we connect two or
more actors in AKKA because that's the basic for creating any topology?
Thanks
I don't think that topologies make any sense in Akka.
As you have noticed, the basic tool for creating topologies is a connection between two entities. But such connection cannot exist in Akka, because any actor can send a message to any actor. This is the foundation of actor model, after all.
Of course, you can try and emulate some topology manually, but I cannot see any use for it.