Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 18 08:45
    Zetanova commented #5152
  • Sep 18 07:37
    Zetanova synchronize #5152
  • Sep 18 07:15
    Zetanova commented #5273
  • Sep 18 05:12
    Zetanova synchronize #5273
  • Sep 18 04:51
    Zetanova synchronize #5273
  • Sep 17 16:56
    Aaronontheweb commented #5273
  • Sep 17 08:49
    Zetanova review_requested #5273
  • Sep 17 03:30
    Zetanova synchronize #5273
  • Sep 17 02:41
    Zetanova commented #5273
  • Sep 17 00:44
    Arkatufus closed #5284
  • Sep 16 21:14
    Arkatufus opened #5284
  • Sep 16 20:05
    Arkatufus synchronize #5282
  • Sep 16 19:47
    Aaronontheweb commented #5273
  • Sep 16 19:28
    Aaronontheweb commented #5273
  • Sep 16 19:18
    Aaronontheweb commented #5273
  • Sep 16 19:16
    Aaronontheweb commented #5273
  • Sep 16 19:15
    Aaronontheweb commented #5273
  • Sep 16 19:11
    Aaronontheweb commented #5273
  • Sep 16 16:52
    Aaronontheweb commented #4989
  • Sep 16 16:17
    dependabot[bot] labeled #5283
Aaron Stannard
@Aaronontheweb
@markusschaber so running Akka.NET inside Blazor isn't really possible on the client side
due to WASM being single-threaded and restricting access to lots of primitives Akka.NET depends on (i.e. most synchronization mechanisms)
it can run fine in Blazor server mode though - done that here: https://github.com/petabridge/DrawTogether.NET
Is something like that generally thinkable using Akka.NET, maybe using Akka.Remoting with a custom protocol over websocket, or by using Akka.IO and "proxy actors" which forward and filter messages?
so this is what we do with things like https://cmd.petabridge.com/
it's all done via Akka.IO
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