CODEWITHSUNDEEP
scalaparallel-processingakkaakka-actor
Alwin Doss
Alwin Doss

Reputation: 972

When to create an Akka Actor

I have a REST service which services only one POST request. I want to use an actor to process the request. However I don't know if I should create one actor and derive all the requests using this actor or should I create an actor every time I get a request. What are the pros and cons of these choices. Also, how is it parallel execution when I create one actor and use that actor to process all my requests. It certainly looks like sequential execution. I would want to understand this as well.

Upvotes: 0

Views: 217

Answers (3)

Andrew James Ramirez
Andrew James Ramirez

Reputation: 524

I agree with what @pamu said. Actors are cheap. But be mindful that if ever you are gonna use a singleton Actor, do not make it stateful it will cause trouble.

And if you are gonna use Futures to do intensive work (which you should do). Make sure you give them specific ExecutionContext / Dispatcher. Using the global dispatcher or ExecutionContext is not good.

Or in each api you have, create a certain dispatcher to control the # of Actors that will work on that kind of endpoint / api.

For example you have "/get/transactions"

specify a dispatcher that would only spawn this # of thread. For this api.

The advantage of this is you can control the # of threads and resources your app uses. When it comes to dealing with heavy traffic. This is a good practice.

Upvotes: 1

Jegan
Jegan

Reputation: 1751

I would create an actor per request and use the "tell" pattern to delegate the work to the newly created actor. If the REST framework you use supports completing the request from another actor (Spray, Akka-HTTP does), then you can complete the request from this new actor. This way your request handling actor is free to handle the next request.

I find this a wonderful resource that explains the pros & cons of ask & tell and per-request-actors. It can be helpful to you.

Upvotes: 1

Nagarjuna Pamu
Nagarjuna Pamu

Reputation: 14825

If you use one Actor requests are queued inside the actor mail box and are processed one by one by the actor. This is sequential and not recommended.

Thats why it is said

One actor is no actor.

Create a manager Actor which manages other actors. As actors are quite cheap you can create one actor for every request without any problem. Do db interactions and other heavy computation using a future and direct results of the future to request handling actor using pipeTo pattern.

Use actors only to divide and distribute work and use Futures to do compute intensive work.

Upvotes: 1

Related Questions