I’m thinking about writing a supervisor strategy so I can log unhandled exceptions and using it everywhere. Got a couple of questions:
1) Is this stupid?
2) Is there anyway to add a new default strategy?
1) Is this stupid?
2) Is there anyway to add a new default strategy?
Also, following the docs to add serilog, but I get: An unhandled exception of type 'Akka.Configuration.ConfigurationException' occurred in Akka.dll
Additional information: Logger specified in config cannot be found: "Akka.Logger.Serilog.SerilogLogger, Akka.Logger.Serilog"
@BenGale using a custom supervisor strategy could be problematic if you want to do remote-deployment as that supervisor strategy might not serialize well over the wire (that can be solved) also, changing to another "normal" supervisor strategy in some use case might lead to loss of logging for that actor
We do some funky stuff in some supervision strategies in cluster/remoting, but in general, supervisor strategies should be side effect free (not required but its not really the responsibility of the strategy to also log)
if you want a consistent behavior across your own actors, the easiest would be to just create a sub class of e.g. ReceiveActor and override PreRestart or some other lifecycle event
sorry I read messages instead of exceptions ;)
Had no idea PreRestart gave me the exception, we already have a profiling base that I can add this stuff to. Thanks guys!
Still can’t get the serilog stuff to work though :-/ The nuget package is definitely in that project...
if you browse the files in the bin folder, is the akka serilog adapter and serilog itself in there?
Im using serilog in my project right now...
loggers = ["Akka.Logger.Serilog.SerilogLogger, Akka.Logger.Serilog", "Akka.Event.StandardOutLogger, Akka"] works fine here... got to be some sort of issue with missing files(?)
are there any samples out there for akka.clustering running within webapi?
@tstojecki https://github.com/petabridge/akkadotnet-code-samples/tree/master/Cluster.WebCrawler - ASP.NET MVC, but same technique applies
that is exactly my issue, this app runs great until i switch it to webapi, my code is almost identical, except that the bootrstraping logic happens inside the owin startup logic of the webapi
then i get this exception:
No transport is loaded for protocol: [akka], available protocols: [akka.tcp]
same exact configs
do WebAPI apps automatically load settings from App.config?
err, Web.config?
yes
because it sure sounds like the Akka.NET HOCON section isn't getting loaded automatically
here's how to check it
var section = (AkkaConfigurationSection)ConfigurationManager.GetSection("akka");
foreach (var port in ports)
{
//Override the configuration of the port
var config =
ConfigurationFactory.ParseString("akka.remote.helios.tcp.port=" + port)
.WithFallback(section.AkkaConfig);
//create an Akka system
var system = ActorSystem.Create("ClusterSystem", config);
//create an actor that handles cluster domain events
system.ActorOf(Props.Create(typeof(SimpleClusterListener)), "clusterListener");
}
manually load the configuration section and pass it into your
ActorSystem
and see if that works
where does ports come from?
i get it
i am getting 0 routees response now, i have been getting that on occasion with the mvc project too...is there a specific order you start the apps in? lighthouse, then mvc, then win service?
we refactored the WebCrawler sample a couple of days ago
and ran into this problem
when you first create the clustered router
if you have
allow-local-routees=off
in HOCON configuration
there is a VERY strong chance that if you try to send a message to that clustered router immediately after creating it that it will have no routees
and that's not a bug - it's a consequence of the gossip protocol that Akka.Cluster users
cluster routers have to populate their routee table on-the-fly, versus how local and remote routers do it: at startup
they have to wait for the local
Cluster to send them MemberUp messages about the availability of particular nodes
and even if all of your nodes are already connected at the time you create the router
because routers are the only type of actor who can process multiple messages simultaneously (which is why they are higher throughput)
your "message that needs to be routed" might be processed before the cluster router receives any of its gossip messages
and it will be sent to dead letters
is that something we should be checking in code? the MemberUp message? or have some retry logic in place?
so you basically have to add retry-able delivery semantics to anything that uses a cluster router right away
which is what I did
i see, that was added to the sample,i will be sure to check it out
private void Ready()
{
// kick off the job
Receive<IStartJobV1>(start =>
{
Subscribers.Add(start.Requestor);
JobStarter = Context.System.Scheduler.ScheduleTellRepeatedlyCancelable(TimeSpan.FromMilliseconds(20),
TimeSpan.FromMilliseconds(20), Self, new AttemptToStartJob(start), Self);
});
Receive<AttemptToStartJob>(start =>
{
var self = Self;
CoordinatorRouter.Ask<Routees>(new GetRoutees()).ContinueWith(tr =>
{
return new CrawlCanStart(start.Job, tr.Result.Members.Count());
}).PipeTo(self);
});
Receive<CrawlCanStart>(start => start.NodeCount > 0, start =>
{
var downloadRootDocument = new DownloadWorker.DownloadHtmlDocument(new CrawlDocument(start.Job.Job.Root));
//should kick off the initial downloads and parsing
//var routees = CoordinatorRouter.Ask<Routees>(new GetRoutees()).Result;
CoordinatorRouter.Tell(downloadRootDocument);
JobStarter.Cancel();
Become(Started);
Stash.UnstashAll();
});
Receive<CrawlCanStart>(start =>
{
Log.Debug("Can't start job yet. No routees.");
});
ReceiveAny(o => Stash.Stash());
}
I
Ask the routee to GetRoutees, which will return a Routees message.
If
Routees.Members.Count() is greater than zero, then the router has cluster nodes it can talk to
so I basically wait in a loop until the
Members.Count is greater than zero
because I actually don't know if any of the crawler nodes are up
this allows me to check that easily without having to muck with cluster gossip itself, which would be a PITA
the other thing you can do is just use an
AtLeastOnceDeliveryActor from Akka.Persistence
and have that send to the router
that would also solve this problem
still trying the config, it looks like i am getting the right section information out of the web.config
with this
var section = (AkkaConfigurationSection)ConfigurationManager.GetSection("akka");
you can debug on it and expand the
section.AkkaConfig object, which is where you'll find the Config that we usually automatically load into the ActorSystem
take a look inside and see if your settings are actually there
if they are not, then it looks like we need to log a bug for Web.config hijinks with WebAPI
@/all BTW, off-topic but I thought you all might be interested in reading it. Wrote about a recent high-profile ".NET scalability fail" that happened this week and what we can learn from it: http://www.aaronstannard.com/voat-scalability/
would it be useful to create a fork with a webapi project in the sample? I can create that ...
once you've done that send me an email at aaron@petabridge.com
so I can take a look and see what's up
@Horusiath queued up Akka.NET v1.0.3 for release - this will solve #1044. Going to push it out live today. Doesn't include any of the other updates that have been made to the
/dev branch.
I'm working on my own plugin release, but nupkg I release is f**ked up somehow: I got
System.ArgumentException: '7' is not a valid version string. for some reason, and there is not a single '7' digit in my entire project
maybe i can help