These are chat archives for akkadotnet/akka.net

13th
Jun 2018
Hyungho Ko
@hhko
Jun 13 2018 05:26
ReferencesBroken_472.png
I'm using Visual Studio 2017 15.7.2 and .NET Framework 4.7.2
Some references are broken after installing Akka and Akka.Remote 1.3.8 nuget.
Whtat's the problem?
Hyungho Ko
@hhko
Jun 13 2018 05:38
Some references are broken on .NET Framework 4.7.1 and 4.7.2
4.7 is ok.
Sandeep Chandra
@sandeepc24
Jun 13 2018 09:37
Is Asp.net core can handle 1.15 million requests per second https://www.ageofascent.com/2016/02/18/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/, will there be any benefit in using Akka.net with it ?
DaKaLKa
@DaKaLKa
Jun 13 2018 10:31
Hi. Are there any experiences with .NET Core 2.1 ? I ported an application to .NET Core 2.1 and now I randomly have some "Can't join seed-node" problems - sometimes all nodes can connect, sometimes just one and sometimes non of them. I was forced to downgrade to .NET Core 2.0 to fix the problem - everything works again without problems (tested with 1.3.6 and 1.3.8). I use the official docker-images from Microsoft - currently running one seed node and two service nodes. Anyone else having problems?
Aaron Stannard
@Aaronontheweb
Jun 13 2018 12:48
@v1rusw0rm @sandeepc24 it's not an apples to apples comparison
they're not benchmarking a single TCP connection performing all of those HTTP requests
which is how we benchmark and run Akka.NET
they're benchmarking the total load of the webserver across many incoming connections and requests in parallel - on top of that, those builds aren't even doing any serialization which isn't realistic for any web applications that are more complex than a static file server
@DaKaLKa I've run some local benchmarks with .NET Core 2.1 but haven't launched a full blown cluster yet
@hhko the only major change Akka.NET 1.3.8 introduced was the DotNetty v0.4.8 upgrade
in terms of downstream dependencies
might want to do a clean reinstall of Akka.NET on that runtime - sounds like the issue is how the VS tools are handling updates to the downstream packages
Hyungho Ko
@hhko
Jun 13 2018 13:23
@Aaronontheweb I have tested it on Akka.Remote 1.3.0 ~ 1.3.8
there is the same problem.
Aaron Stannard
@Aaronontheweb
Jun 13 2018 13:24
it's only v1.3.8 that has this issue on .NET 4.7.2?
but they work fine on 4.7.1?
Hyungho Ko
@hhko
Jun 13 2018 13:24
only on .NET 4.7.1 and 4.7.2
other .NET Framework versions are fine.
Aaron Stannard
@Aaronontheweb
Jun 13 2018 13:24
hmm... ok, sounds like there's some platform issue then on those two
which we don't current test on, since we assume that anything that targets .net standard 1.6 or .net 4.5 should run fine on those
would you mind creating an issue for this? we'll investigate
@DaKaLKa also, would you create an issue for the platform issues you ran into on .NET Core 2.1? I doubt your issues are related to .NET 4.7.2 but still, want to have something we can refer back to in case other users have the same problem
I ran the RemotePingPong benchmarks on .NET Core 2.1 and we definitely did see a perf increase there
about 10% higher than .NET Core 2.0
but that's the extent to which I've had a chance to play with it
Hyungho Ko
@hhko
Jun 13 2018 13:46
@Aaronontheweb Of course not. ^^;;;
Ismael Hamed
@ismaelhamed
Jun 13 2018 14:07
@hhko I think .NET 4.7.1 and above has built-in support for NETStandard. Maybe the NETStandard.Library referenced by Akka is interfering here!?
var timestamp = reader.GetInt64(TimestampIndex);
Ismael Hamed
@ismaelhamed
Jun 13 2018 14:11
Mind opening an issue? I think it is used in the BatchingJournal though.
Onur Gumus
@OnurGumus
Jun 13 2018 14:12
yes but that line is useless. I thought it is a bug. maybe you forgot something.
nathvi
@nathvi
Jun 13 2018 19:10
Designing my first production Akka system.
edwinparker
@edwinparker
Jun 13 2018 20:29
Hi, we're trying to setup remote deploy actors that use DI (the remote actor). Is this possible to do in akka.net? We get a parameter name cannot be null (actorSystem).
Chandra Sekhar Manginipalli
@leo12chandu
Jun 13 2018 20:33
@edwinparker - Did you register the actorsystem with the Container of the DI resolver you are using.
edwinparker
@edwinparker
Jun 13 2018 20:36
Yes...we are doing something like this (var propsResolver = new AutoFacDependencyResolver(container, ActorSystem);).....it works local...but not remoting. Is there a workaround for remoting if this is not possible?
Chandra Sekhar Manginipalli
@leo12chandu
Jun 13 2018 20:38
Ah ok ok. Sorry, then thats not it. I have it working on a cluster but it resolves just within that node of the cluster. Did not try "deploying" the actors remotely. Although, now I am curious if you have referenced the actor code in the remote node as well and made sure the actorsystem is the same between remote and the current node.
Gustavo Eduardo Mendoza Ramírez
@gemr142388
Jun 13 2018 20:39
Hi everyone, some one can help me with an error with CircuitBreaker?
edwinparker
@edwinparker
Jun 13 2018 20:47
@leo12chandu Yes we have referenced the actor code in the remote node (using a shared library) and the actorsystem name is the same. I read in the comments here from a couple years ago that this might not be possible but I'm wondering if that has changed.
Aaron Stannard
@Aaronontheweb
Jun 13 2018 20:54
@gemr142388 what error is that?
@edwinparker there's a way to use DI when remotely deploying an actor
but you kind of have to decouple the steps
remotely deploy a parent actor that doesn't use DI at all
and then have the parent locally deploy a child that does use DI
that will allow you to use the container definitions that are defined in the remote process
to inject all of the settings into the remote actor
edwinparker
@edwinparker
Jun 13 2018 21:00
Thanks @Aaronontheweb that makes sense...we will give that a try
Gustavo Eduardo Mendoza Ramírez
@gemr142388
Jun 13 2018 21:10
@Aaronontheweb The ciruit breaker is open, but I got the following error

``"System.InvalidOperationException: There were not enough free threads in the ThreadPool to complete the operation. at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state) at System.Net.Http.HttpClientHandler.StartGettingResponse(RequestState state) at System.Net.Http.HttpClientHandler.StartRequest(Object obj) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at Core.HttpWebUtilImpl.<SendRequest>d__9.MoveNext()"

"Akka.Pattern.OpenCircuitException: Circuit Breaker is open; calls are failing fast
at Akka.Pattern.HalfOpen.<Invoke>d4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Akka.Pattern.CircuitBreaker.<WithCircuitBreaker>d
33.MoveNext()"```

Aaron Stannard
@Aaronontheweb
Jun 13 2018 21:11
funnily enough, we merged a pull request that fixed this bug this morning
akkadotnet/akka.net#3505
should be included in our latest nightlies
let me see if they've run yet today... might be too early still
ok yeah, nightlies don't run yet for another four hours
I just manually kicked off a nightly build now though
should be online sometime within the hour
give that a try until we release Akka.NET v1.3.9
Gustavo Eduardo Mendoza Ramírez
@gemr142388
Jun 13 2018 21:18
@Aaronontheweb Thanks, I will update version and test, thanks a lot
Aaron Stannard
@Aaronontheweb
Jun 13 2018 22:10
:+1: :clap:
onward and upward