These are chat archives for akkadotnet/akka.net

16th
Feb 2017
Bartosz Sypytkowski
@Horusiath
Feb 16 2017 06:05
@DamianReeves per node or per cluster?
per node - we usually do that through actor system extensions. Most of them have their custom actors (often 1 per node) attached. But this can be generalized to creating actor directly under the supervision of root actor (either /user or /system).
per cluster - cluster sharding, but you probably know about that
maxplanck76er
@maxplanck76er
Feb 16 2017 07:23
Hello, I just would like to know if akka .net actors could communicate remotely with akka actors running on a JVM ? Thanks.
Maxim Cherednik
@maxcherednik
Feb 16 2017 07:24
nope
David Smart
@dsmart
Feb 16 2017 07:55
Must be .NET to .NET to serialise/deserialise. All you could do is introduce a non-Akka channel and independent data format.
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 10:51
How can an actor get its Akka.Remote hostname which is configured in akka.hocon? Self.Path.Address.Host is empty for local actors...
Shamsul Amry
@ShamsulAmry
Feb 16 2017 10:56
I'm building a multitenanted Akka app. In that app I'm using EventStream for local pub/sub. Since it's multitenanted, I wonder if it's a good idea to have separate EventStream per tenant (and not using the ActorSystem's EventStream). Tried, technically it's working, just wonder if I am overlooking any possible issues going down this path.
Shamsul Amry
@ShamsulAmry
Feb 16 2017 11:07
@ZoolWay One way would be to read directly from the config.
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 11:18
Hm, ok, I am checking how far I can go using Context.System.Settings.Config.GetString("akka.remote.helios.tcp.hostname")
Arjen Smits
@Danthar
Feb 16 2017 12:09
@ShamsulAmry if your using the local evenstream you can easily create partition spaces by prefixing the topic your subscribing and publishing on with the tenantid
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 12:19
It seems I cannot get a simple distributed pubsub to work with Akka.Cluster.Tools 1.1.3.32-beta. When I launch a second node it joins the cluster (something working for months now) but all publishing only happens on each node by itself, never reaches other nodes. Using Hyperion serializer with Akka 1.1.3.
Is there anything that can be configured towards distributed pub-sub? The interesting blog posts states something about akka.cluster.pub-sub.role which is nowhere documented? https://petabridge.com/blog/distributed-pub-sub-intro-akkadotnet/
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 13:12
Any hints how I can debug pub-sub? there does not seem to be any log messages...
Stephen Newman
@goodisontoffee
Feb 16 2017 13:17
@ZoolWay I had a similar problem, I was using a broken version of ClusterTools - make sure you get the latest pre-release package and give it a try
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 13:18
@goodisontoffee Thanks for your response. Currently using 1.1.3.32-beta which looks like it is the latest version. Which one are you working on?
Stephen Newman
@goodisontoffee
Feb 16 2017 14:06
@ZoolWay same version here, the propagation of the subscriptions does take a small amount of time - are you allowing any?
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 14:07
first node goes up. can wait for a minute, second node goes up (subscribe too) and publishes, the first node does not get it... it think that should be enough time
Stephen Newman
@goodisontoffee
Feb 16 2017 14:15
@ZoolWay My solution was nodes one and two up and joined to a seed node. Subscription registered on node 1, took a few moments for node 2 to receive knowledge of this subscription (via gossip I presume) - eventually consistent.
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 14:15
hmm, ok
when node 2 goes up maybe it will not forward to node 1 because it needs time to know about node 1 having subscribed (minutes before)
Stephen Newman
@goodisontoffee
Feb 16 2017 14:16
that's my assumption, give node 2 some time to receive that knowledge
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 14:16
I wanted something like "hey i am here, who else is here doing this?"
did not occur to me that I should not ask before others told node 2 they have subscribed...
I'll give it a try
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 14:33
@goodisontoffee You were right. It takes some time. But it feels odd to wait 10s before publishing... either I will have to publish in intervals or there should be some kind of message when the subscription "is ready"...
Arjen Smits
@Danthar
Feb 16 2017 14:53
there is an subscribeAck message that is returned once the subscription has succeeded
you can listen to that (?)
Stephen Newman
@goodisontoffee
Feb 16 2017 14:53
Does that get fired once all the other nodes in the cluster have received knowledge of the subscription, or does the local pub sub mediator fire it once it's accepted the subscription?
Arjen Smits
@Danthar
Feb 16 2017 14:55
that is fired once there is cluster consensus
Stephen Newman
@goodisontoffee
Feb 16 2017 14:55
sweet
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 15:08
@Danthar I disagree. I was publishing on SubscribeAck but it did not get delivered to other nodes
Either thats a bug or it is just because my own subscription is committed to the cluster - but not that I received all of the other subscriptions
Arjen Smits
@Danthar
Feb 16 2017 15:16
@ZoolWay thats odd. As far as i understand it. You should receive an SubscribeAck back once the subscription process has been completed on all nodes. /cc @Horusiath
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 15:17
let me sum up my observation:
node 1 starts and subscribes to topic, gets subscribe-ack, publishes and of course only itself gets the message
node 2 starts and subscribes to topic, gets subscribe-ack, publishes and only itself gets the message - after some time (just tested 10s but might work with less) publishes again and both nodes get the messages
to the SubscribeAck seems to acknoledge my new subscription but not necessarily that I got all subscription from other nodes... when you think about it, how could you ever know you got all of those?
Arjen Smits
@Danthar
Feb 16 2017 15:29
@ZoolWay the local mediator publishes its state via cluster gossip to the other nodes
the interval at which it does so is configurable via de config
not sure at what interval its implemented now
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 15:33
default config is 1s
but like always with time, you cannot 100% be sure
for my use case I will require to publish update regulary so I can live with that for now
Arjen Smits
@Danthar
Feb 16 2017 15:34
When the node is UP, the local mediator receives the current cluster state
not sure at what time that state is received
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 15:35
Does the CurrentClusterState include all cluster-known subscriptions?
Arjen Smits
@Danthar
Feb 16 2017 15:35
no only the nodes
so it knows which nodes have which roles
The more i look at this, the more it becomes clear that there is a clear tradeoff between availability and consistency
if it would be highly consistent, it would mean pubsub would not be available untill it received all updates.
if you have a large cluster
that can potentially take a while
so the default implementation opts for availability
while consistency can be added fairly easy
hmm, i was thinking in terms of atleastonce delivery mechanisms on your publish messages
but that would mean on broadcast messages you would have to know how many subscribers there are
which is no good
Vagif Abilov
@object
Feb 16 2017 15:39
@Horusiath We have probably found the cause for an issue in SQL adapter but something needs to be clarified, I commented here: akkadotnet/Akka.Persistence.SqlServer#46
Ricky Blankenaufulland
@ZoolWay
Feb 16 2017 15:43
@Danthar Yeah, turns out you have to decide. So if you want everyone in pub-sub to know something, you have to repeat to near yourself to be eventually consistent.
Arjen Smits
@Danthar
Feb 16 2017 16:40
Well i suppose if you as a publisher really want to make sure every listener has received your message. As the architect of your application, you would know where your subscribers live. So you would know that for example, there is always 1 subscriber per node. That knowledge would enable you to do an atleastonce delivery mechanism. In combination with querying the cluster state to know how many nodes there are up.
And usually if you publish a message. And a new node that is coming up, does not receive that message. Well thats to bad. It will get the next one.
Shamsul Amry
@ShamsulAmry
Feb 16 2017 20:59

@ShamsulAmry if your using the local evenstream you can easily create partition spaces by prefixing the topic your subscribing and publishing on with the tenantid

@Danthar by "prefixing the topic", did you mean to add a property to the event object instance passed to Context.System.EventStream.Publish() and filter on that property when receiving the messages?