Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:57
    Aaronontheweb closed #3877
  • 15:57
    Aaronontheweb commented #3877
  • 15:56

    Aaronontheweb on dev

    Persistence TestKit documentati… (compare)

  • 15:56
    Aaronontheweb closed #3889
  • 07:27
    dependabot-preview[bot] labeled #3999
  • 07:27

    dependabot-preview[bot] on nuget

    Bump FluentAssertions from 4.14… (compare)

  • 07:27
    dependabot-preview[bot] opened #3999
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] edited #3995
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3993
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.9.1… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3991
Nikita Tsukanov
@kekekeks
Oh, thanks
jcwrequests
@jcwrequests
I have been playing around trying to find a good way to do stateful actors in a hierarchy. After talking with @Aaronontheweb that HashPooling was not a good idea so I came up with a sample project. Besides adding become logic I was wondering if anyone had any thoughts or criticism on how to model this using Akka.
I was going to combine some of the ideas with what @rogeralsing posted in his blog. Anything anyone would like to share is welcome.
Arjen Smits
@Danthar
Any known issues with Akka running on .Net 4 ?
Roger Johansson
@rogeralsing
Dont think anyone have tried tbh
Arjen Smits
@Danthar
yeah me either
when I start thinking about it. There might be some TPL stuff
and there would be some minor perf issues in places where the concurrent collections are used. Those where horrible in perf in .Net 4
meh horrible is a bit much. But they weren't great.
Arjen Smits
@Danthar
Do you guys make .Net 4 builds ?
ah, nuget says nope.
So in short: No known issues, but its not officially supported.
ugh! I hate this: https://skillsmatter.com/skillscasts/4081-greg-young-4081 "Because of its privacy settings: This video cannot be played here"
Arjen Smits
@Danthar
@nvivo the new routing docs are great. But could use some extension on what resizers are and how they work.
Natan Vivo
@nvivo
@Danthar, I'll take a look at that. Thanks
Arjen Smits
@Danthar
@rogeralsing question. About DI and scopes. Currently the docs say that Actors must not have the singleton scope, since its not supported
However, that implies that other scope types are supported. But I think thats wrong, because as far as i understand it
only the transient scope is supported.
Due to how Akka works with location transparency and the lifetime of actors
but i could be wrong :P so im asking ;)
Roger Johansson
@rogeralsing
You can still remotedeploy DI actors, the DI will occur on the remote system as the DI support is based on actor producers
Assuming the correct config exists on the remote system that is
Natan Vivo
@nvivo
@rogeralsing so DI shouldn't affect remoting or clustering?
Arjen Smits
@Danthar
@rogeralsing Ah I remember reading about that. But that is not what I was referring to.
Roger Johansson
@rogeralsing
I havent tried it our but in theory it should work just fine as the props that are pushed to the remote system only contain the typename for the actor producer
Arjen Smits
@Danthar
lets assume a non-remoting/clustering scenario for now.
lets say you are using an actorsystem in asp.net
Arjen Smits
@Danthar
and you register your actors with an DependencyPerHttpRequest scope
Gerjan
@GerjanOnline
Roger, who are these people?
Roland Kuhn?
Arjen Smits
@Danthar
which would mean that the actors are disposed at the end of an httprequest. What i'm thinking is that this cannot work.
Roger Johansson
@rogeralsing
@GerjanOnline yes, Roland Kuhn (akka lead for typesafe) holding the akka frame there.. no idea who the others are
Gerjan
@GerjanOnline
okay thanks
Roger Johansson
@rogeralsing
@Danthar hmm yes that sounds weird.. I have look that up
Gerjan
@GerjanOnline
i think the java guy is Brian Goetz https://twitter.com/briangoetz
not sure, but thanks
Natan Vivo
@nvivo
@rogeralsing, what prevents us from allowing system/context.ActorOf<ISomeInterface>() using DI internally instead of the context.DI().ActorOf<T>?
Arjen Smits
@Danthar
@rogeralsing I think that any DI scope which effectively takes away lifecycle management from the ActorSystem, are not supported. Because it would mean that an Actor could be disposed without the Actor system being aware of it, or being the one who actually starts the dispose. Which in turn would cause all kinds of wierd stuff. As far as i can tell.
But maybe you guys have some voodoo code to manage those scenario's.
@nvivo nothing. Just that when you do that with Actor types. They wont be initialized properly. I take you mean something like this? :
This message was deleted
 myStaticDiContainer.Resolve<typehere>();
Natan Vivo
@nvivo
not exactly
what I mean is more the semantics than the implementation
imagine I have an actor that requires constructor parameters
today I'm required to create the props with DI or manually, and then pass to ActorOf
this creates 2 different ways to declare exactly the same thing
man.... personally I can explain things much better
Arjen Smits
@Danthar
Oh