CODEWITHSUNDEEP
akkaactor
Nico
Nico

Reputation: 811

Akka / Actors: Share a single, limited resource among the actor hierarchy

I'm learning Akka, and I'm struggling to find a good pattern to share a single, limited resource among the whole actor hierarchy.

My use case is that I have a HTTP REST endpoint to which I'm only allowed 10 simultaneous connections at any time. Different actors at different levels of the hierarchy need to be able to make HTTP REST calls. I'm using non-blocking I/O to make the HTTP requests (AsyncHttpClient).

The obvious solution is to have a single actor in charge of this REST resource, and have any actors who want to access it send a message to it and expect a reply at a later stage, however:

In addition, how to deal with "blocking" the client actors when 10 connections are already in progress, especially since I'm using non-blocking I/O? Is it best practice to re-send a message to self (perhaps after some time) as a wait pattern?

I also thought of a token-based approach where the resource manager actor could reply with "access tokens" to client actors that needs to access the resource until exhaustion. However it means that client actors are supposed to "return" the token once they're done which doesn't sound ideal, and I will also need cater for actors dying without returning the token (with some sort of expiration timeout I guess).

What are the patterns / best practices to deal with that situation?

Updated: To indicate I'm using non-blocking I/O

Upvotes: 1

Views: 198

Answers (1)

Maciej Falski
Maciej Falski

Reputation: 249

My suggestions would be:

  • Use the Error Kernel pattern, as the REST endpoint, as you said, is a fragile code (I/O operations can generate any kind of errors). In other words, Master/Worker actor hierarchy, where Workers do the job, while Master does any supervision
  • Connection limit could be handled by Akka Routing feature, where number of Routees is, in your case, 10. This also drops into Master/Worker category
  • Addressing - either way sounds good
  • Connection timeout - to be handled by a client code, as it's always done in a majority of network libs.

Upvotes: 1

Related Questions