Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 19:12
    IgorFedchenko commented #3998
  • 18:29
    Aaronontheweb commented #3998
  • 18:24
    Aaronontheweb opened #3998
  • 18:19

    Aaronontheweb on fix-readme-logo

    (compare)

  • 17:30
    Aaronontheweb milestoned #3973
  • 16:38
    jaydeboer opened #3997
  • 15:53
    Aaronontheweb synchronize #3973
  • 15:52

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 15:52

    dependabot-preview[bot] on nuget

    (compare)

  • 15:52
    dependabot-preview[bot] closed #3996
  • 15:52
    Aaronontheweb commented #3996
  • 14:53
    Aaronontheweb commented #3973
  • 12:20
    IgorFedchenko commented #3973
  • 12:17
    IgorFedchenko commented #3973
  • 11:58
    IgorFedchenko synchronize #3973
  • 11:33
    IgorFedchenko commented #3973
  • 11:25
    IgorFedchenko synchronize #3973
  • 07:04
    dependabot-preview[bot] labeled #3996
  • 07:04
    dependabot-preview[bot] opened #3996
  • 07:04

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

Arjen Smits
@Danthar
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
@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
@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
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

@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?

Arjen Smits
@Danthar
@ShamsulAmry Yup. that is one way. Thats the easiest way. However if you feel that creating a separate infrastructure for doing multi-tenant pub/sub is a better fit. By all means. Do so. There is no obvious right or wrong here.
Shamsul Amry
@ShamsulAmry
@Danthar Thanks. Asked in case I will be losing out on any features I didn't know about if I used new EventStream() for each tenant instead of using the one pre-created with the ActorSystem.
Голодный Монстр
@Kalinin_Aleks_twitter
Hi all! I need help! I have the problem with "EndpointDisassociatedException". If I do restart remote actor I am receiving the message in logs:
[akka://ARS-Runner-System/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fARSSystem%40127.0.0.1%3a2551-1] Association with remote system akka.tcp://ARSSystem@127.0.0.1:2551 has failed; address is now gated for 5000 ms. Reason is: [Akka.Remote.EndpointDisassociatedException: Disassociated
at Akka.Remote.EndpointWriter.PublishAndThrow(Exception reason, LogLevel level)
at Akka.Remote.EndpointWriter.Unhandled(Object message)
at Akka.Actor.ActorCell.<>cDisplayClass109_0.<Akka.Actor.IUntypedActorContext.Become>b0(Object m)
at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
at Akka.Actor.ActorCell.ReceiveMessage(Object message)
at Akka.Actor.ActorCell.AutoReceiveMessage(Envelope envelope)
at Akka.Actor.ActorCell.Invoke(Envelope envelope)]
And I can't catch this Exception for restarting the system because it is not "RemotingLifecycleEvent" and internal Exception. How can I handle the error? Thanks
Arjen Smits
@Danthar
@Kalinin_Aleks_twitter The Exception is normal. It happens when the remote node becomes disassociated. This can happen for various reasons.
if you want to be notified when that happens
you can use the local system.EventStream to subscribe to AssociationErrorEvent
Голодный Монстр
@Kalinin_Aleks_twitter
Yes, but as I can understand in my case was invoked PublishAndThrow(Exception reason, LogLevel level, bool needToThrow = true) which is trying to publish "DisassociatedEvent". Am I wrong?
So I should do subscribe to DisassociatedEvent
Arjen Smits
@Danthar
The log shows the fact that you Disassociated. Internally this is communicated via the EndpointDisassociatedException exception. My guess is that you are getting this on the sender side ?
Thickar
@Thickar
Hi there, I want to connect an SQLDateReader object as source Enum for Akka streams source, but i cant figure out how! could any one help?
Ralf
@Ralf1108
is it possible to check if there are messages in the stash?
Maxim Cherednik
@maxcherednik
why do you want to do this? :)
Ralf
@Ralf1108
because i am a little confused :D
i have an actor... which gets a message. the actor is changing state and start processing stuff. because the original message can not be answered yet I stash it
when the processing is finished then all messages are unstashed and actor switches back to orginal state
now the original message can be answered
this works
but i also added passivation to the actor
so if the passivate message arrives during processing .. the passivate message will be handled and actor is shutdown
the orginal sender wont get a nice repsonse.. but instead could deathwatch the actor :-(
so if i could check if there are currently stashed messages i would also stash the passivate message... that should work
does this makes sense?
i could keep track of stashed messages count by myself. wondered if the count or "not empty stash" could be checked
maybe using reflection :P
Maxim Cherednik
@maxcherednik
just thinking what I would do
what is this passivation message? what do you mean by this?
Arjen Smits
@Danthar
Its a pattern
Ralf
@Ralf1108
yes, i implemented it like this.
parent sent passivate to child and stops forwarding messages to child
child stops it self when nothing doing anything else
parent gets informed via deathwatch
Arjen Smits
@Danthar
@Ralf1108 what you can do. Is once you receive the passivate message
unstash all messages, then send the passivate message to yourself again. Basically forward it. Because you also change the state of your actor (switching from processing to the other state).
You could have the passivate message be handled differently
so if your in processing and receive a passivate. Unstash and forward passivate message to yourself
then all stashed messages get handled