If you dont define anything it will fallback to whatever is in the hocon config
And its also used for testing :P
@jackowild we probably already seen your PR come up. but I forwarded your request internally as well. Can't make any promises as to when someone will get around to it though.
@Danthar but how does the cluster sharding plugin tell the persistence plugin which config to use? I mean, if I look at the persistence plugins they all know how to persist to a journal using the default journal config (eg. akka.persistence.journal.sql-server). They do not check the config for the cluster setting, so how does the cluster sharding persistence config (as configured via the journal-plugin-id, as you said) flow to the persistence plugin?
For example, this plugin (https://github.com/alexvaluyskiy/Akka.Persistence.Azure/blob/dev/src/Akka.Persistence.AzureTable/AzureTablePersistence.cs#L85) always uses the same config section 'akka.persistence.journal.azure-table' for its persistence. It seems not able to get a different config for eg cluster sharding. This means both normal actor state and cluster sharding state will end up in the same table (as configured by that one config section)
with the sql-server persistence plugin it seems to work when I configure it like this (https://github.com/promontis/stylister.sample/blob/master/Liking/Stylister.Liking.Downloader/settings.hocon), but I don't get how the akka.persistence.journal.sharding config section is passed to the sql-server persistence plugin
Hey guys, question: whenever using a supervising actor for persistent actor (in case where they cannot really be
created or recreated on demand), is the approach of creating actors while replaying event mentioned in "akka in action"
book (https://github.com/RayRoestenburg/akka-in-action/blob/master/chapter-persistence/src/main/scala/aia/persistence/ShoppersSingleton.scala#L71)
the best way to go? Or some streaming from some other source would be more applicable?
created or recreated on demand), is the approach of creating actors while replaying event mentioned in "akka in action"
book (https://github.com/RayRoestenburg/akka-in-action/blob/master/chapter-persistence/src/main/scala/aia/persistence/ShoppersSingleton.scala#L71)
the best way to go? Or some streaming from some other source would be more applicable?
hey guys. I have this scenario where I need to able to do things like determining for a given user: nearby shops, distance from a shop, distance and time away from delivery person/courier.
For this I decided to create a "Locations Service" and the idea is to have other services actors make requests to it to get location related data using Akka.Remote .
For example: Shop Service asks locationsService which are the nearby shops for a given point/user location (latitude, longitude). My problem is that currently I have the dbs separated by each service. How would shop service know which shops to present to the user? Right now all I have is geo spatial data stored in locations service db and a name for each entry. I feel like I'm missing something and I might be even confusing myself :/
@defrag2_twitter As long as it's idempotent and won't fail (in your example it's get-or-create an actor), it should be good to go
however, I could have a persistent actor registering "login" events for each shop, so this way I could tell which shops are available to order from
i have a question... i can'T seem to get akka testing to run wiht nunit 3 (any version). i seen there were some fixes done around an issue regarding nunit3... but i can't seem to make it work. anyone got any clues?
Hey guys, I'm scaling my application with cluster sharding, and have a look at multinode test kit (http://getakka.net/articles/networking/multi-node-test-kit.html). How it supposed to be debugged? is there any guide? may be runners for Resharper Tests, as for NBench ? (https://github.com/Pro-Coded/Pro.NBench.xUnit) I can imaging only attach VS to multinode test runner, and it seems to be painful and long process. (
@andreyleskov debugging MNTR specs is a dark art
having done it for years, I have a couple of approaches I use
first - relying on logging as your primary source of information is the lowest-friction path
trying to debug 4-5 processes running concurrently
is going to end poorly usually
especially if you don't know where the problem is
is a free add-on to Visual Studio
zero clue if that supports .NET Core or not
that can help get the debugger attached to breakpoints in the child process
so my methodology is this: use logging to smoke out the error
the MNTR runner will produce detailed logs for each node
and the overall test run report will show you which nodes had failed assertions
get enough log data to form a theory as to why the thing might be failing
conditional break points are you best friend here too, btw
should only start firing once you're close to the error condition
multi-node tests, by their very nature, are big and cumbersome
but they're the most reliable way to put real-world theories around handling things like failover, network issues, etc, to the test
I have a failover scenario where a cluster singleton has to migrate from one node to another