akkadotnet/akka.net

Port of Akka actors for .NET

nathvi

@nathvi

Also I'd change the line:
var ci = _data.Count - 1; // child index; start at end
To something like:
var endChildIndex = _data.Count - 1;

@AndreSteenbergen

AndreSteenbergen

@AndreSteenbergen

I am actually not so much inclined to change that code, as it is a straight copy from the ListPriorityQueue from akka.net sources on github

seqnum and priorityCalc yes, I think you are correct.

nathvi

@nathvi

If you have to add a comment to explain what the intention of the statement is, then the variable names are poor.

Not always, but in this case, I think having a more explicit name for the var would be much better than littering the code with comments.

AndreSteenbergen

@AndreSteenbergen

I understand what you are saying. my goal here was to keep as close to original source as I could, but changing the functionality in such a way we can end up with a priority queue with correct order.

nathvi

@nathvi

if (rci <= li && comparator.Compare(_data[pi],_data[rci]) > 0) return false; // check the right child too.

The entire check inside of the if should be a single bool variable. The comment just confuses things.
Code never lies. Comments sometimes do.

If you can make code more readable, do it. We spend at least 90% of our time reading code. Not writing it.

AndreSteenbergen

@AndreSteenbergen

This is my original source:

https://github.com/akkadotnet/akka.net/blob/3f924fda8d6ca55c5af90a710d23be8ce36d5c7a/src/core/Akka/Util/ListPriorityQueue.cs

I understand what you are saying, but I am still not inclined to change copied stuff, when there is proven code, as in don't fix if it ain't broken.

nathvi

@nathvi

It's not "broken" as in the functionality works, but it's "broken" in that it's not as clean as it could be.

I think it's worth cleaning up the code if it makes understanding it easier.

AndreSteenbergen

@AndreSteenbergen

nathvi

@nathvi

If I had a 2000 line function that was nested 8 levels deep and passed all my unit tests, it's probably still worthless as far as being composable or understandable by other people. This is an extreme case, but I think you get me.

AndreSteenbergen

@AndreSteenbergen

From the comment you made I understood you ;)

nathvi

@nathvi

nathvi

@nathvi

omfg

} // ListPriorityQueue

Comments like this really irk me.

AndreSteenbergen

@AndreSteenbergen

little too much copy paste I guess. ;)

nathvi

@nathvi

GAH!

AndreSteenbergen

@AndreSteenbergen

I see it is 4 year old code I copied over ;) @rogeralsing made the commits for the PriorityQueue

nathvi

@nathvi

DAMN YOU! lol

AndreSteenbergen

@AndreSteenbergen

I removed the closing tag comments ;) and seqnum is now SequenceNumber ;)

nathvi

@nathvi

Alex Hofer

@alexhofer

Hey all, I am running into some weird issues with Docker and clustering. My cluster works perfectly fine outside of Docker, but while running in docker I get association errors after about 15 seconds of it being up. Before this Lighthouse shows both nodes as being welcomed to the cluster and moving to up. After that nothing happens out of the ordinary on the nodes, they just start throwing association errors:

**From Lighthouse**
[INFO][07/05/2018 16:29:59][Thread 0019][[akka://hub-system/system/cluster/core/daemon#107465231]] Leader can currently not perform its duties, reachability status: [Reachability([akka.tcp://hub-system@localhost:26100 -> UniqueAddress: (akka.tcp://hub-system@localhost:26800, 1690450065): Unreachable [Unreachable] (1)][akka.tcp://hub-system@localhost:26800 -> UniqueAddress: (akka.tcp://hub-system@localhost:26100, 1417053438): Unreachable [Unreachable] (1)])], member status: [$akka.tcp://hub-system@lighthouse:4053 $Up seen=$True, $akka.tcp://hub-system@localhost:26100 $Up seen=$False, $akka.tcp://hub-system@localhost:26800 $Up seen=$False]

**From a Node**
[Akka.Remote.EndpointWriter] [WARN] : AssociationError [akka.tcp://hub-system@localhost:26100] -> akka.tcp://hub-system@localhost:26800: Error [Association failed with akka.tcp://hub-system@localhost:26800] []
[remoting] [WARN] : Tried to associate with unreachable remote address [akka.tcp://hub-system@localhost:26800]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: [Association failed with akka.tcp://hub-system@localhost:26800] Caused by: [System.AggregateException: One or more errors occurred. (Connection refused tcp://hub-system@localhost:26800) ---> Akka.Remote.Transport.InvalidAssociationException: Connection refused tcp://hub-system@localhost:26800

Has anyone else run into this?

matneyx

@matneyx

What's the proper way to grab an IActorRef for other Actors within the same system?

I'm initializing my ConsoleWriterActor immediately after starting up the Actor system, inside the Main method of my command line program

static void Main(string[] args) {
            _actorSystem = ActorSystem.Create("FileWatcherActorSystem");
            _consoleWriter = _actorSystem.ActorOf<ConsoleWriterActor>("consoleWriter");

And then I'm trying to grab that same actor two children deep, in the first Actor that needs to actually write anything.

_consoleWriter = Context.System.ActorSelection("consoleWriter").Anchor;

But when I try to Tell the consoleWriter anything, I get info about a dead letter...

I've also tried this using the absolute and relative paths to the consoleWriter.

Alex Hofer

@alexhofer

Is that an actor you will be sending messages to from all over?

Bartosz Sypytkowski

@Horusiath

@matneyx by default every actor is placed under user guardian actor. In your case, the path to it is actually /user/consoleWriter. However the fact that you need to do something like that points, that you've got some design problem in the first place.

@alexhofer are you sure that nodes can target each other?

matneyx

@matneyx

@Horusiath -- That very well could be the case. Any resources you'd recommend to help me fix that?

Alex Hofer

@alexhofer

@Horusiath thats what I'm thinking the problem actually is, they can both communicate with Lighthouse but cant talk to each other. Though I can't figure out why. Based on the console logs in Docker they are attempting to communicate with their assigned ports. Both running on localhost:26100 and localhost:26800. Which match my configurations. Maybe I am just misunderstanding how Docker works.

Eduardo

@EduardoSantosGit

Hello!

@bruno-alencar asked the following question above.

Can anyone help me?

I'm looking for a way to combine Rest API with Akka.net in a Cluster System. I would not connect the rest api receiver inside the cluster,
but sending messages for the cluster group.
I saw something about recepcionist, but when I tried to use inside the lighthouse system, It occurred exception because it was required that
know all messages types.

Is there any way to use these things together with best performance?

Would you have any suggestions to help us?

Bartosz Sypytkowski

@Horusiath

@matneyx pattern depends on what you actually want to use it for - but IActorRef can be easily passed either in message or constructor to other actors.

matneyx

@matneyx

Thanks

Alex Hofer

@alexhofer

@matneyx you can also have a static class that you assign IActorRefs to when you create them on system startup. For things like that console writer which I assume you will use all the time across multiple actors.

Bartosz Sypytkowski

@Horusiath

@EduardoSantosGit you can limit most of the clustering features of akka to some subset of nodes by configuring them with roles

this includes distributed pub sub and cluster client

but tbh I don't know what problem do you really have - cluster members must share the common knowledge about used message types.

Bruno Alencar

@bruno-alencar

@Horusiath, @EduardoSantosGit and I are using differents machines in the cluster.
We have 5 lighthouses, but using pub sub they don`t need to know the message because the serialization is json and the current message goes directly to the subscriber.
The only required configuration on lighthouse is the serialization type.

Bartosz Sypytkowski

@Horusiath

@bruno-alencar @EduardoSantosGit you can set HOCON config akka.cluster.pub-sub.role = "my-role" to tell that only actor systems which have that role, are expected to have distributed pub-sub capabilities

Also, they should have DistributedPubSub.Get(system) initialized on startup

Bruno Alencar

@bruno-alencar

@Horusiath the role solves if the actor is inside the cluster, right? But we want to remove the rest api from the cluster. If we will use receptionist, where will we have to put the Actor?

Bartosz Sypytkowski

@Horusiath

@bruno-alencar you mean, that you don't know the initial contact list, because that actor system is not part of the cluster and lighthouse nodes doesn't expose that info?

Bruno Alencar

@bruno-alencar

If we put the receptionist inside the lighthouse, for safety reasons. They may know all the messages, because the messages will be serialized

@Horusiath Yes, if we put the lighthouse address + /receptionist for example, we can't find the actor as initial contact

Bartosz Sypytkowski

@Horusiath

@bruno-alencar you can always enhance lighthouse with custom actor that when asked, could respond with list of addresses to other nodes i.e. having a given role

Where communities thrive

People

Repo info

Activity