We have a Java Play Framework Application which we want to scale out into a cluster. The only issue is that there are services ran by the Akka Scheduler once per day, and we don't want these services triggered by all the instances. Here are some of the options we have thought of:

  1. Extracting the scheduler operations as a separate service: But these operations require certain utilities and services from the main application which will be needed to be replicated in the new service. Not sure if this repetition is the best way to go.
  2. Expose the scheduler operations as an API and hit it from a separate application/service once every day.
  3. Remote Method Invocation of the scheduler operations from another service.
  4. Using the Akka Cluster services to scale and coordinate the scheduler operations.
  5. Using Zookeeper like services to run the application: However, as the application is not distributed per se, maintaining a zookeeper configuration for just the scheduler operations seem a lot of effort.

Moving forward, we want the best way to make fewer code changes and maintain the application. This may include changing the time of the day these services are running via an environment variable or conf file or something else in the easiest fashion without touching the code. Considering these needs, what would be the best way to scale out the application?

  • So if I understand correctly, you're trying to ensure that the scheduler is shared across all your nodes, but only invoked on a single node? Oct 11, 2019 at 21:29
  • Yes @ChuckAdams That is precisely what I want. Oct 12, 2019 at 20:21

1 Answer 1


It's been many years since I've used Akka and have never had to deal with it clustered, but some quick research suggests Akka Scheduler isn't really meant for long-term jobs like this, and that you should use akka-quartz-scheduler instead for this sort of thing. Both of these have an instance per actorsystem, so you still have the same problem, making only one instance actually run the job.

Off the top of my head there's two good ways I can think of to do this, the first being a a classic approach: have them contend on a shared lock, which you can do with zookeeper or or an RDBMS if you're already using one.

Another is to generate an ID for each job that will be the same across nodes, send it to an idempotent message queue (you could use Camel for this), then just contend on the queue. This might actually fit better into Akka's semantics than waiting on a lock.

I suggest not touching RMI, for anything, ever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.