and then unit test with a mock / fake version of that wrapper class
that way you're not live-firing emails during testing
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.
is the SMTP connection persistent?
or is it something you need to open / close per-request
not persistent... it connects to the server for each email send.
yeah I'd just have the actor fire up a new client on each request like you're doing then
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:
@Aaronontheweb does using code contracts put any constraints on cross platform compatibility? I.e running on mono.
not as far as I know
we use them in NBench / Helios / DotNetty
all of those can run on Mono
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.
@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)?
@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.
I have some questions about Akka.NET and cluster routers. Hope someone can help me clear things up...
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?
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?
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?
@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
@Danthar ok, thanks for verifying my assumptions
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?
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."
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?
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!
this is hard case when you try to think about consistency i.e. should it be allowed to call the same scheduled timeout twice?
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
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
@pablocastilla I suggested a solution at SO
so I would have to write it, wouldn't I?
also for the first case ddata module would be good, but it's still in development
eventually something like redis would do the job
@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
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?
Bart de Boer
@Aaronontheweb any idea what those threads are actually waiting for?