Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple active journals #43

Closed
scullxbones opened this issue Aug 25, 2015 · 10 comments
Closed

Support multiple active journals #43

scullxbones opened this issue Aug 25, 2015 · 10 comments
Assignees

Comments

@scullxbones
Copy link
Owner

@devluencer-089
Copy link

Does this mean overriding journalPluginId and snapshotPluginId has no effect in 1.0.5

@scullxbones
Copy link
Owner Author

This was to support multiple instances of this plug-in with different configurations. The use case I was considering was data migration between different settings.

I'm pretty sure, though haven't tested, that you can use this plug-in with others if you override the pluginId like you suggest.

@devluencer-089
Copy link

This was to support multiple instances of this plug-in with different configurations.

I think this is exactly what we need. Let me explain our setup:

We currently have multiple services, each running in a dedicated process (service) writing to different mongo DBs. Each process (service) hosts an actor system and multiple persistent actors. There is one single instance of your plugin per Service. Plugin-configurations are almost identical across services, except for the following property:

akka.contrib.persistence.mongodb.mongo.db="dog" //each service uses a different DB

That works fine. One actor system and one plugin instance per service.

We also read from those DBs using persistent views. Unfortunately one service needs to read from multiple sources, meaning multiple DBs. That's not supported within one actor system as you can only refer to a single plugin-id. Our current workaround is to create one actor system for each DB. That way we can define multiple journals pointing to different DBs. That's causing a lot of overhead and problems, particularly in conjunction with clustering.
Our goal is to have one actor system per Java-process (aka. Service) that can refer to multiple instances of the same plugin with different configurations. That way each group of persistent actors/persistent views could decide where to write to and where to read from.

I assume this is what you mean with:

Support configuration-per-plugin-instance

Any idea how we can achieve this with akka 2.4 and 1.0.5?
Any help is appreciated.

@scullxbones
Copy link
Owner Author

Yes that's exactly what this ticket is here to support. The ability to support multiple instances of this particular plugin with different configurations. My thought was migrations, but your use case is quite a good fit as well.

The answer is you can't yet do this with 2.4 and 1.0.5 (hence the ticket 😉). 2.4 gives the framework, but this plugin still needs to support configuration override. I think it's very doable, but it depends on how much information akka is providing the plugin about the config object - that's the primary research point that I need to do.

Given that you voiced a need for this sooner rather than later, i'm good with making it the next ticket I work on, unless you'd like to submit a PR, of course. If not, I can take a look this weekend.

As a persistent view user, I would be interested in your thoughts on the new read journal approach as a replacement.

@devluencer-089
Copy link

Thanks for your quick reply.

I would love to contribute to your plugin but given my tight schedule and poor Scala skills, I'd say it's not feasible right now. 😉 If you could take a look this weekend and maybe evaluate what needs to be done, I'd be very thankful.

I am really shocked this feature has not been made a requirement for 2.4 by the akka-team given how limited the current configuration space is. Anyone working on a real project would want to control the way persistent entities are written in the database layer. Maybe not into dedicated DBs like we do, but at least into dedicated collections (or tables in RDBMS or whatever criteria the datastore supports). Configuration on a per actor basis is a must to my mind. Glad you see the need for this improvement...

As far as the new experimental query API is concerned, I am not sure if it really solves all the problems we have with PersistentView. One of the most important improvement - query all persistenceIds - is somewhat useless without the possibility to have multiple configurations. Tagging might help here, but it's not available in 2.4.x. So basically it's useless to us.
I will open a forum thread on akka-user once I was able to play with it in our system. I make sure you are notified.

@scullxbones scullxbones self-assigned this Oct 1, 2015
@scullxbones
Copy link
Owner Author

I can't put multi-configuration on the akka team - it has to do with how I chose to set up the configuration early on, as this plugin has been around pretty much since the beginning - hindsight is always 20/20. If I had done configuration differently, it would probably work fine with 2.4 with no changes.

Good I look forward to your feedback, I don't think many have started consuming the ReadJournal changes yet. There's another query that mimics persistent view behavior, EventsByPersistenceId I think it's called. I've implemented all of the standard queries but the tagging so far - which is in place in 2.4, just not implemented on this plugin yet (it's coming too). In addition there's a custom "AllEvents" query which will probably eventually show up in the core product. So far these are only the current state of the system, not tailable cursors yet, that'll be big.

@scullxbones
Copy link
Owner Author

So good news, akka supports what's needed. From the docs

The journal plugin class must have a constructor without parameters or constructor with one
com.typesafe.config.Config parameter. The plugin section of the actor system's config will be passed in
the config constructor parameter.

Will just need to rearrange a few things to do overrides, but shouldn't be too bad.

scullxbones added a commit that referenced this issue Oct 4, 2015
* Looks for a `overrides` config object to supply
* Fixes issue #43
* keys at the level `akka.contrib.persistence.mongodb.mongo` are assumed
@scullxbones
Copy link
Owner Author

@michaelOM -

Ok you should be able to use this via providing all the typical parameters "the old way" and adding an overrides config object inside each plugin definition. For the sake of keystrokes it assumes keys in this config are rooted in akka.contrib.persistence.mongodb.mongo

e.g.:

akka-contrib-mongodb-persistence-journal1 {
  class = "akka.contrib.persistence.mongodb.MongoJournal"
  plugin-dispatcher = "akka-contrib-persistence-dispatcher"
  overrides = {
    mongouri = "mongodb://host1:27017/db1"
  }
}

akka-contrib-mongodb-persistence-journal2 {
  class = "akka.contrib.persistence.mongodb.MongoJournal"
  plugin-dispatcher = "akka-contrib-persistence-dispatcher"
  overrides = {
    mongouri = "mongodb://host2:27017/db2"
  }
}

Let me know if you have any issues or if this works for you.

@devluencer-089
Copy link

@scullxbones
Thank you (again) for being so quick in implementing new features. This feels like enterprise-grade support. 👍

akka-contrib-mongodb-persistence-journal1 {
  class = "akka.contrib.persistence.mongodb.MongoJournal"
  plugin-dispatcher = "akka-contrib-persistence-dispatcher"
  overrides = {
    mongouri = "mongodb://host1:27017/db1"
  }
}

That's exactly how I imagined the configuration to look like. So basically we have something like prototypical inheritance for plugin configurations.

We'll get to it right away. I let you know how if it worked out.

@scullxbones
Copy link
Owner Author

This feels like enterprise-grade support.

Uh oh, most "enterprisey" support i've gotten in my career is pretty bad 😉 ... thanks! it's much easier when the product is simple and there's a queue of one. Look forward to your feedback, positive or negative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants