CODEWITHSUNDEEP
javascalaakka
blue-sky
blue-sky

Reputation: 53786

How to store data to be shared between multiple actors?

I've an actor which sends a web service request to an external system. Multiple actors are created for multiple requests. An authentication token is required to be sent as part of the request. This token times out after x minutes and when it does a new token is to be created. Is there a standard mechanism I should use for sharing this token (string) between actors?

Approach I'm considering is for the supervisor to create the token and pass this token to the child actors. But how should the supervisor store the same token value for each actor? Does this supervisor need to be a singleton which contains the token attribute, reason I suggest singleton is so that the token value is not re-instantiated each time the supervisor is created.

I'm using akka for java framework.

Update : If I encapsulate the web service request and storage of the token string in its own actor how is this token shared with other actors ?

Update 2 :

To solve this problem (sharing data between multiple instances of same Actor) I suggest introducing a static variable to the actor. This variable will be shared between actors and re-initialized when the token is no long valid.

Here is the pseudocode : 

class MyActor {

    private static String userToken = "";


    @Override
    public void onReceive(Object argMessage) throws Exception {

        String response = initiateRequest(userToken);
        if(response == tokenNotValid){
            userToken = getToken();
        }
    }

    private String getToken(){

        String tokenValue = createRequestToAccessToken

        return tokenValue;
    }
}

This could be a bad practice ? - introducing mutable state via the userToken attribute. But I think this is a clean solution as all of the logic is encapsulated within the actor. Any potential issues with this approach ?

Upvotes: 1

Views: 2580

Answers (2)

lmm
lmm

Reputation: 17431

The token is a piece of state. It belongs in its own actor - not the supervisor, but an actor in its own right - which can also be responsible (or have children responsible) for creating a new token when the current one times out. Other actors can request the token the usual way, by sending a message to the token actor and getting a reply with the token.

I would not normally expect a supervisor to be being recreated - a supervisor should be as simple as possible, responsible only for restarting failed actors. Any actual processing should happen in other actors, so that the chances of the supervisor itself failing are minimal.

Responding to your update: The actor that's responsible for storing the token string should probably be responsible for using it. If the token is used in a standard way on every request, other actors could send their requests to the token actor, which can then forward them to the actual http actor.

If there are a few different ways of using the token, the actor could accept different types of message for these different cases. Put the logic with the state it needs access to.

Response to update 2: Mutable statics are a terrible idea - it's global mutable state (also the practical problems of statics in a distributed system e.g. classloader issues). Your code has race conditions - it's possible two requests will update the token at the same time; depending on how the service at the other end responds to this this may break. The whole point of the actor model is to avoid such things. If you're going to do this then why bother using actors at all? (This is not a rhetorical question - maybe your problem doesn't need actors? In which case you could make your code simpler by not using them). But even if you want to use a non-actor approach, I'd recommend using a singleton object (potentially static, but ideally managed by your DI framework or however you're putting together your application) containing a mutable field, rather than just a static field.

Upvotes: 4

Guy Bouallet
Guy Bouallet

Reputation: 2125

I think that you are trying to solve a common authentication problem related to Single Sign On (SSO). Dependening on your target environment, you should be able to find a standard solution. The supervisor approach reminds me of the Central Authentication Service. You may check if it is suitable for you or also have a look to the protocols already integrated in akka.

Upvotes: -1

Related Questions