These are chat archives for akkadotnet/akka.net

1st
Jun 2016
Aaron Stannard
@Aaronontheweb
Jun 01 2016 00:00
that would get scooped up by another process and delivered in batch
but that was kind of a special case with how I had to deliver them
(wasn't really over email - just a similar notification system)
what I would do in your case
is create a wrapper around the SMTPClient
can be a thin one
and then unit test with a mock / fake version of that wrapper class
that way you're not live-firing emails during testing
qwoz
@qwoz
Jun 01 2016 00:03

hm... I'm using SmallestMailboxPool over the actor that sends out emails to have a bunch available. That actor simply does:

Receive<Email>(email => // SMTPClient stuff here );

so I'd think it wouldn't actually finish and clean up the actor prior to that call completing.

Aaron Stannard
@Aaronontheweb
Jun 01 2016 00:04
is the SMTP connection persistent?
or is it something you need to open / close per-request
qwoz
@qwoz
Jun 01 2016 00:05
not persistent... it connects to the server for each email send.
Aaron Stannard
@Aaronontheweb
Jun 01 2016 00:05
got it
yeah I'd just have the actor fire up a new client on each request like you're doing then
qwoz
@qwoz
Jun 01 2016 00:07
so this is probably some NUnit incompatibility that I'll just need to work around by mocking it for now. I wanted to be able to see in my email account that the email is actually formatted the way I want since the piece that actually uses this isn't fully implemented yet.
the joys of prototyping :smile:
Alex Achinfiev
@aachinfiev
Jun 01 2016 01:18
@Aaronontheweb does using code contracts put any constraints on cross platform compatibility? I.e running on mono.
Aaron Stannard
@Aaronontheweb
Jun 01 2016 01:18
not as far as I know
we use them in NBench / Helios / DotNetty
all of those can run on Mono
hidavidpeng
@hidavidpeng
Jun 01 2016 05:15
Hi I'm using the Supervisor to catch the exception. But How can I get the message in Supervisor so that I can re
Hi I'm using the Supervisor to catch the exception. But How can I get the message in Supervisor so that I can re-read the message again? thank you.
@Silv3rcircl3 thank you. i read it later. I'm writing the demo with books.
Bartosz Sypytkowski
@Horusiath
Jun 01 2016 06:37
@artem-karnaukh which version of Akka.Cluster.Sharding are you using? Also what steps have you made before an error occurred (maybe hard/graceful shutdown of a node)?
Peter Bergman
@peter-bannerflow
Jun 01 2016 07:07
@Aaronontheweb reading the documentation on Akka.Cluster in the web crawler example project, in the section on ASP.NET integration (https://github.com/petabridge/akkadotnet-code-samples/tree/master/Cluster.WebCrawler#best-practices-for-aspnet-and-akkanet-integration) the router is created with a RemoteJobActor. But that don't match the actual code in the repo, where the router is created with Props.Empty (https://github.com/petabridge/akkadotnet-code-samples/blob/master/Cluster.WebCrawler/src/WebCrawler.Web/Global.asax.cs#L23). Maybe the readme should be updated to reflect this to avoid confusion
artem-karnaukh
@artem-karnaukh
Jun 01 2016 09:22
@Horusiath hey, thanks for the response. I ve just updated from 1.6 to the latest beta and everything works just fine. Thanks a lot for the amazing sharding module.
Peter Bergman
@peter-bannerflow
Jun 01 2016 12:44
I have some questions about Akka.NET and cluster routers. Hope someone can help me clear things up...
  1. As far as I understand it, in order to pass messages between nodes in a cluster, the message must go through a a cluster-aware router. Correct?
  2. And for that I can either use a group or pool router. Difference is that the group router sends the mesasge to predifned routees that might or might not exist at the target node. The pool router on the other hand deploys its routees on the target node. Correct?
  3. For deciding where to route message (and in case of pool router, deploy routees), the use-role property in the cluster part of the deployment config is used. Correct?
Arjen Smits
@Danthar
Jun 01 2016 14:39
@peter-bannerflow
1: A cluster-aware router is a piece of infrastructure that makes it easier for you to communicate with the cluster as a whole. It adds a level of abstraction. You can communicate with nodes in your cluster directly if you want. But in order to do this properly you'd end up rebuilding alot of the management stuff that a cluster aware router already does for you. But if the out-of-the-box (OOB) cluster routers dont fit your use-case. You can certainly do this.
2: Yes
3: Yes
Peter Bergman
@peter-bannerflow
Jun 01 2016 15:33
@Danthar ok, thanks for verifying my assumptions
Peter Bergman
@peter-bannerflow
Jun 01 2016 15:50
What about if I pass an IActorRef in a message to some other node in the cluster, will an actor receiving that message be able to send a direct message to that IActorRef?
Marc Piechura
@marcpiechura
Jun 01 2016 16:11
@peter-bannerflow yes
Peter Bergman
@peter-bannerflow
Jun 01 2016 16:18
Right, thanks 😊
Marc Piechura
@marcpiechura
Jun 01 2016 16:22
Np
JaspritBola
@JaspritBola
Jun 01 2016 16:47
I'm looking at some logs here, and
I'm looking at some logs here, and I'm noticing that the "Association failure ---> Akka.Remote.Transport.AkkaProtocolException: The remote system has a UID that has been quarantined. Association aborted." eventually turns into a "Akka.Remote.Transport.InvalidAssociationException: Association failure ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown."
JaspritBola
@JaspritBola
Jun 01 2016 17:03
Another odd behaviour is that I'm still getting Association failures after I downed the address. The cluster state shows the status is down. Do I also have to call leave on the address to stop association attempts?
Pablo Castilla
@pablocastilla
Jun 01 2016 17:15
Hi! I have just left a question on stackoverflow. Basically is which is the best way to assure that a timeout message is sent, maybe some could help. Thanks!
Bartosz Sypytkowski
@Horusiath
Jun 01 2016 17:30
@pablocastilla what do you mean by timeout message? With fire-and-forget messages, there is nothing to wait for
Pablo Castilla
@pablocastilla
Jun 01 2016 17:33
@Horusiath I mean defered messages. When you want to get notified at a certain exact time.
Bartosz Sypytkowski
@Horusiath
Jun 01 2016 17:43
this is hard case when you try to think about consistency i.e. should it be allowed to call the same scheduled timeout twice?
Pablo Castilla
@pablocastilla
Jun 01 2016 17:45
that would be ok. The actor could discard the second message. But I have to make sure it gets there, we have business timeouts
another option could be to make sure certain actors are recreated after a reboot or a machine missed? :S
Bartosz Sypytkowski
@Horusiath
Jun 01 2016 17:47
this would require to have some scheduler working on each node and distributed "database" where the timeout requests would we written to, so they could be taken over by other nodes in case of unexpected crash
@pablocastilla with cluster sharding I guess you could
(but I haven't checked if actors would be recreated in case of crash, only when migrated between machines)
Bart de Boer
@boekabart
Jun 01 2016 17:49
@pablocastilla I suggested a solution at SO
Pablo Castilla
@pablocastilla
Jun 01 2016 17:49
so I would have to write it, wouldn't I?
Bartosz Sypytkowski
@Horusiath
Jun 01 2016 17:49
also for the first case ddata module would be good, but it's still in development
eventually something like redis would do the job
Pablo Castilla
@pablocastilla
Jun 01 2016 17:54
@boekabart I think I got the idea and it should work. Thanks so much. Tell me what you think about the comments plz
Bart de Boer
@boekabart
Jun 01 2016 21:18
After wrapping my Akka.Remoting application in a Topshelf service, it won't quit anymore. CTRL-C does 'stop' the service OK, but then the process hangs (with the console window open). Attaching a debugger shows 6 threads waiting for UnfairSemaphore.Wait():
Not Flagged > 12944 8 Worker Thread akka.remote.default-remote-dispatcher_1 Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait Normal
any clue what might cause this?
Tomasz Jaskula
@tjaskula
Jun 01 2016 21:25
Hi
Bart de Boer
@boekabart
Jun 01 2016 21:59
@Aaronontheweb any idea what those threads are actually waiting for?
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:07
@boekabart that's what the ForkJoinDispatcher runs on top of
as for why they're all waiting - should be because they're expecting work
however, if you're terminated the actor system by then
and they still aren't shutdown
it means we're not properly disposing of them
Bart de Boer
@boekabart
Jun 01 2016 22:08
according to the log, remoting is correctly shut down
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:08
ok
that's a bug then
I'll file an issue for it
need to dispose all dispatchers on shutdown
thanks for reporting it Bart
Bart de Boer
@boekabart
Jun 01 2016 22:08
It seems to only happen when using topshelf
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:09
hmmm...
is it possible that with the way Topshself is configured in your instance
that those threads are running in the foreground?
and not the background?\
latter being the default
hi @tjaskula
Bart de Boer
@boekabart
Jun 01 2016 22:09
I haven't changed any dispatcher configuration
hold on, I did create dispatcher in foreground, in fact, for some system tasks
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:10
I use Topshelf too
ohhhhhhhhh
that would do it
Bart de Boer
@boekabart
Jun 01 2016 22:10
isn't that just thread prio?
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:10
nah
the foreground threads are meant to be literally used for user-facing elements
so like the UI thread in an app
Bart de Boer
@boekabart
Jun 01 2016 22:11
let me quickly test that theory
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:11
or the thread that owns the console UI
I don't have the details 100% clear off the top of my head anymore
but basically a process can't exit until its foreground threads are joined
Bart de Boer
@boekabart
Jun 01 2016 22:13
Yeah, that fixed it.
still a normal console app (not topshelf) didn't suffer from it, it seems. But that one also did less work on that threadpool, so apples and oranges
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:14
akkadotnet/akka.net#2028
just created that
foreground vs. background doesn't change priority
it's the exit behavior that gets affected
Bart de Boer
@boekabart
Jun 01 2016 22:15
ok, clear! Re priority btw, again/still suffering from remote disconnects during load; what was that timeout setting again?
I think - there's other settings in there you can adjust also
Bart de Boer
@boekabart
Jun 01 2016 22:18
thanks, let's try that..
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:18
one thing we might be able to do, possibly
is add a configuration setting to the ForkJoinDispatcher and the dedicated thread pool
which will allow you to change the priority
I'm comfortable leaving the default where it is
but also fine with users being able to change it
Tomasz Jaskula
@tjaskula
Jun 01 2016 22:19
quick question, does the code shared between the actors needs to be synchronized with lock or maybe there some other ways of doing things ?
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:19
@tjaskula you mean shared memory?
every actor instance's memory should be made private
and not shared
if you do need to share data
you should pass that data in an immutable message
that way there's no need for locks and synchronization
and you can still have a high degree of parallelism
Tomasz Jaskula
@tjaskula
Jun 01 2016 22:21
I meat rather using for example a common portion of code
like for example you write it once and then you use it for several actors
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:21
oh
just methods / functions?
Tomasz Jaskula
@tjaskula
Jun 01 2016 22:22
let say I have something I want to use on PreRestart for every actor
like writing to some DB log or something
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:34
ah
every one of those actors
should be given their own instance of that object
part of the goal of the actor model
is to avoid locking / shared state concurrency
the other thing you can do
if you don't want every actor to have to hold onto a DB connection
is to create a single type of actor who's job it is to write stuff to the DB
and give everyone else a reference to an instance of that actor type
Tomasz Jaskula
@tjaskula
Jun 01 2016 22:41
thanks @Aaronontheweb
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:42
@JaspritBola hmm... after downing a node it should be removed
and no further attempts should be made to contact it
if it's not getting removed then that's a bug
I'll take a look at that
Tomasz Jaskula
@tjaskula
Jun 01 2016 22:48
@Aaronontheweb this means than in F# passing the same function around is the same issue. I have to use a reference to an actor or embed behavior in a class and pass instances
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:49
I'm not an F# expert but that sounds right
Bart de Boer
@boekabart
Jun 01 2016 22:56
@Aaronontheweb the acceptable heartbeat pause does the trick, as in, it delays the disassociation to 60 seconds now. It happens only and always when the system is under load (ingesting a file, leading to 100k's of messages through the ActorSystem). these peaks can and do last up to 60 or more seconds, during which, apparently, not a single heartbeat makes it back and forst. The comms themselves work, since the 'work' command (1 single message) comes from the remote. The work being done is parallel enough to keep my 4 cores busy for a while. But in a way it's strange that not a single one heartbeat makes it through, right?
qwoz
@qwoz
Jun 01 2016 22:56

if I want an actor to send a message to all its children, is this the best way to do it?

Context.ActorSelection("*").Tell(message);

or is there a better way?

Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:57
Context.GetChildren()
then iterate over the list
qwoz
@qwoz
Jun 01 2016 22:58
is that not the same under the hood? Or is ActorSelection not preferred as it consumes CPU evaluating the expression?
Aaron Stannard
@Aaronontheweb
Jun 01 2016 22:58
But in a way it's strange that not a single one heartbeat makes it through, right?
100% CPU utilization is a bitch
starts to become difficult to keep any promises at that rate
with the newer transport and some of the other changes we're making
Akka.Remote should be more performant
and require less CPU / memory for even better throughput
1.1 will make some big improvements there
1.5 will be even bigger
@qwoz they're different
ActorSelection gets resolved "outside" the actor
Context.GetChildren() is done in-memory, locally
it's a much faster lookup
and doesn't allocate anything
other than a iterator
qwoz
@qwoz
Jun 01 2016 23:02
ok, fair enough... might be nice to have something like that as a convenience method, along the lines of: Context.Children.Tell(message), but I can live with a couple extra lines of code to iterate over it.
Alex Koshelev
@akoshelev
Jun 01 2016 23:44
Hi guys. Are you planning to fix #1700 before akka.cluster goes out of beta?
Bart de Boer
@boekabart
Jun 01 2016 23:44
@Aaronontheweb now I've done a try to limit the # of main threadpool threads to # cores (4). What happens now is that on all 4 threads, the code is 'waiting' for a queue to produce smth, and this queue is fed by a pair of actors running on a dedicated ThreadPool dispatcher.
(code needs to get a unique id non-async, and we've implemented that using a 'client' and (shared/could-be-remote) 'server' actor, both of which are on that dedicated threadpool)
now, I still get a deadlock, all threadpool threads hung on that Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait . Including Remote, by the way
Bart de Boer
@boekabart
Jun 01 2016 23:50
so all 4 akka.remote TPthreads and my 2 dedicted TPthreads all hung on that, because the others are basically very slow (a lot of messages to process, taking 1 second each because that's the timeout for retrieving such an ID from the concurrentQueue.
I've seen this come loose, which I suppose happens after the dispatcher is done with it's batch, but what are those other threads syncing with the main TPthreads for!?
(there's an assumption there)