We have recently started using Akka in our software, but most of our code is still “traditional” Java code. I am now in a position where I want to use Akka with existing classes, but can’t rewrite all the existing code that also uses these classes.
In particular, I have a class that manages a map of data objects. The map is already used concurrently by different threads, so the manager class makes sure that all access to the map is synchronized. I now have to create a cleanup job that removes objects from the map after they have become irrelevant. Since this job is supposed to run asynchronously in the background, I use an Akka agent, i.e. I have code that looks more or less like this:
Agent< ObjectManager > myObjectManagerAgent = new Agent< ObjectManager >( myObjectManager, myActorSystem );
...
myObjectManagerAgent.sendOff(
new Function< ObjectManager, ObjectManager >()
{
@Override
public ObjectManager apply( final ObjectManager objectManager )
{
...
objectManager.erase( irrelevantObjectIds );
return objectManager;
}
}
);
However, the same object manager is also written to directly, without the agent, from several other places within the software. As mentioned, this access is thread-safe, but knows nothing of Akka, actors, or agents.
Now my question is: Is this… well, I’m sure it’s not advisable, but will this work? Or am I shooting myself in the foot here? Even if it will work in general, are there potential traps or safety measures I should know about?
It’s quite normal to use Akka to call into existing code, which is all you’re doing here. You state that the ObjectManager is thread-safe and that other parts of the software use it as well, so there’s no reason to think that introducing Akka will inherently cause problems. On the other hand, you could also move your core logic into an Akka actor, then provide a simple facade over it for your non-Akka consumers.