Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:48
    SeanKilleen edited #5312
  • 16:47
    SeanKilleen synchronize #5332
  • 16:45
    SeanKilleen synchronize #5330
  • 16:27
    Aaronontheweb commented #5330
  • 16:27
    Aaronontheweb commented #5332
  • 16:26

    Aaronontheweb on dev

    Markdown linting: Blockquotes (… (compare)

  • 16:26
    Aaronontheweb closed #5320
  • 14:42
    SeanKilleen synchronize #5330
  • 14:41
    SeanKilleen synchronize #5332
  • 14:40
    SeanKilleen synchronize #5320
  • 14:40
    SeanKilleen commented #5320
  • Oct 21 18:54
    peirens-bart closed #4095
  • Oct 21 18:46
    Aaronontheweb closed #5310
  • Oct 21 18:16

    Aaronontheweb on dev

    Bump Akka.MultiNode.TestAdapter… (compare)

  • Oct 21 18:16

    Aaronontheweb on nuget

    (compare)

  • Oct 21 18:16
    Aaronontheweb closed #5335
  • Oct 21 16:10

    dependabot[bot] on nuget

    (compare)

  • Oct 21 16:10
    dependabot[bot] closed #5299
  • Oct 21 16:10
    dependabot[bot] commented #5299
  • Oct 21 16:10
    dependabot[bot] labeled #5336
Aaron Stannard
@Aaronontheweb
with a strictly controlled serialization format to restrict access to what the client can do
we'll eventually introduce ACL and TLS to that
I think that approach is pretty feasible - the other approach would be to use something like Akka.gRPC (when we port it) to use gRPC as a secure gateway for invoking Akka.NET actors behind the scenes
Robbert
@Robbert-Driven-It
I hope someone here can point me in the right direction. I’ve been experimenting with clusters and the clusterclient. I’m able to communicate with a cluster from an external actor system however the clusterclient doesn’t seem to “fail over” when the cluster loses a node. My expectation was that the clusterclient would automatically keep track of new nodes (running a duplicate console app with a dynamic port) and would start sending messages there once the initial contact node has gone down… Am I mistaken, do I need to manually keep track of nodes?
Aaron Stannard
@Aaronontheweb
My expectation was that the clusterclient would automatically keep track of new nodes (running a duplicate console app with a dynamic port) and would start sending messages there once the initial contact node has gone down… Am I mistaken, do I need to manually keep track of nodes?
ClusterClient does automatically keep track of available nodes
however, if your client is on a node that terminates you will need to recreate it
grabbing some source
in the event that _clusterClient is talking to a node that is dead, the remote receptionist we were previously receiving messages from is now dead
so we just need to re-up our subscribe with a second ClusterClient.Send
in this case, I'm using a ReceiveTimeout to detect when messages coming from the remote client actor have stopped (since we're using pub sub)
a better way of doing it would be to Context.Watch the Sender for any of the messages I receive from the cluster
and then re-send the ClusterClient.Send after I receive a Terminated message
that will have me re-connect to another available node that has a ClusterClientReceptionist running
does that make sense?
@Robbert-Driven-It
Robbert
@Robbert-Driven-It
.. well kind of.. so you are saying the clusterclient keeps track of available nodes but if the cluster node my clusterclient is connected to terminates I need to instantiate a new clusterclient … why does is keep track of other receptionist nodes then? Only for the send all and publish scenarios? Feels odd
Robbert
@Robbert-Driven-It
I mean in order to keep track of available receptionist nodes it would need to monitor members up and down events..right? why wouldn’t it handle the scenario where the receptionist it’s currently connected to is going down and simply connect to one that’s available. I Have a feeling I’m missing something obvious:( or perhaps I’m not fully understanding the purpose of a clusterclient
Aaron Stannard
@Aaronontheweb

.. well kind of.. so you are saying the clusterclient keeps track of available nodes but if the cluster node my clusterclient is connected to terminates I need to instantiate a new clusterclient … why does is keep track of other receptionist nodes then? Only for the send all and publish scenarios? Feels odd

not odd

you have a tandem pair of actors
one on your client
one on the cluster node
if the cluster node shuts down, you just have to tell the client to connect to a new one via ClusterClient.Send
and that's only in a scenario where you're primarily reading from the cluster
rather than writing
in a scenario where the client is actively writing to the cluster you should always be using ClusterClient.Send to do that
I mean in order to keep track of available receptionist nodes it would need to monitor members up and down events..right? why wouldn’t it handle the scenario where the receptionist it’s currently connected to is going down and simply connect to one that’s available. I Have a feeling I’m missing something obvious:( or perhaps I’m not fully understanding the purpose of a clusterclient
the ClusterClient does keep track of this
so you don't have to worry about it
but the actor ON THE NODE YOU ARE TALKING TO which gets created by the ClusterClient.Send
that actor can die if a node terminates
if you're expecting a stream of data to come back from one of those nodes, you need to monitor that actor
the Context.Watch will signal you that the node is gone - or it will signal you that the actor was programmatically terminated (which automatically occurs if the cluster doesn't try to send that client a message within 60 seconds - but that value is configurable)
that client is called a "ClientTunnelActor"
it's the cluster's handle for being able to communicate back to the ClusterClient running outside of the cluster
Aaron Stannard
@Aaronontheweb
https://petabridge.com/cluster/lesson4 - read the section on "Working with ClusterClient" here
this image in particular
if the response tunnel closes you won't receive any more data from the server
for simple request-response interactions via ClusterClient that's probably not a big deal
but for a really long-running stream of data coming back from the cluster
i.e. in our case, continuously streaming stock price and volume updates
you have to monitor that response tunnel actor's health
because if I do a deployment that actor is going to be killed and we'll need to re-create our subscription to ticker data
does that help clarify things?
Robbert
@Robbert-Driven-It
Oke I get that, I ‘m not doing anything like streaming data from the cluster. My case is pretty simple: a backend cluster and a webapi using a clusterclient to send commands and sometimes request-response messages. But once the original cluster node is down not a single clusterclient.send message gets processed. So even though there is a prefectly healthy clusternode the clusterclient isn’t able to reach it.. I think from what you are telling me my expectation that this should work is correct so perhaps There is some configuration or something that’s causing this.
Btw thanks for taking the time to respond.
Robbert
@Robbert-Driven-It
The only complicating factor I can think of is that this remaining node isn’t a seeding node, it has a dynamic port, so it isn’t in the initalcontact list either. Joins the cluster correctly by contacting the initial node and then (after a while) I shutdown the initial node.. the remaining node moves to become a leader but then the webapi clusterclient stops being able to deliver messages to the cluster, it’s like it doesn’t know the remaining node is even there.
Michael Handschuh
@mchandschuh
Is the source code available for Akka.DistributedData and Akka.DistributedData.LightningDb? If so where? I was unable to find it in the akka.net and petabridge github accounts