Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:11
    Aaronontheweb synchronize #4089
  • Dec 12 14:10
    Aaronontheweb synchronize #4086
  • Dec 12 14:09

    Aaronontheweb on dev

    Convert to ImmutableHashSet for… (compare)

  • Dec 12 14:09
    Aaronontheweb closed #4090
  • Dec 12 12:04
    nagytech synchronize #4092
  • Dec 12 11:53
    nagytech synchronize #4092
  • Dec 12 11:49
    nagytech edited #4092
  • Dec 12 11:40
    nagytech opened #4092
  • Dec 12 11:32
    nagytech edited #4091
Roger Johansson
@rogeralsing
Eg if you want to async fill a grid or something
Natan Vivo
@nvivo
hmm. ok!
that's important
Roger Johansson
@rogeralsing
(Those actors should ofc not do heavy work, just update gui in a reactive way)
Maybe a reactive gui app for stock prices are a good example
There is also a pinned thread dispatcher, if you want to dedicate an entire thread to a specific actor
And the forkjoindispatcher, that has its own dedicated threadpool, to avoid noisy neigbours. Eg if some actors are more important than others, it can be isolated from the default shared threadpool
Natan Vivo
@nvivo
Thanks! that helps a lot, gave me already some direction
Arjen Smits
@Danthar
@rogeralsing You basically confirmed what I already expected. Akka uses the DI container to create an instance of your Actor, and after that, Akka is responsible for the lifecycle of the Actor. And not the DI container.
So that confirms my remarks about not supporting any DI lifetime scope except Transient/InstancePerDependency
Roger Johansson
@rogeralsing
it depends on what you mean with scope i guess, lets say you have one dependency that should be recreated for each usage in a dependency graph, that ofc works, and of there is some dependency that should be unique per resolve, that would work too... Eg if a foo have a ref to 5 bars and 3 baz. It could be resolved as 5 bars and one single baz. For the same foo, if foo is injected to the actor
Natan Vivo
@nvivo
@rogeralsing please correct if I'm wrong. Most of the JVM akka docs say that hocon configuration overrides code config. But some tests I did here shows the opposite. For example, if you specify WithRouter(...) in code, it overrides any hocon config. Is it correct that Akka.net gives preference to code over config or I missed something?
Arjen Smits
@Danthar
@rogeralsing I'll do a write-up about this for the http://getakka.net/docs/Dependency%20injection page. Ill run it by you guys when im done.
Arjen Smits
@Danthar
General question to whomever can answer this :P. My ActorSystem behaves in such a way, that it can be in an 'idle' state. Which effectively means that the mailboxes for a few key Actors in my system are empty. Does Akka currently has a way for a user of the framework to monitor this kind of state for an actor ?
So something along these lines:
    actor1.Ask<bool>("areyoubusy")
where the "areyoubusy" is a system(?) message which tells me if there are messages in the actor1's mailbox
Alexander Prooks
@aprooks
I'd beter save info when last message is processed, and on 'areyoubusy' report if any message is processed for the last second/minute whatever you need
Natan Vivo
@nvivo
@Danthar It's a good idea to leave a note on akkadotnet/getakka.net#7 to help coordinate the efforts
depending on the size of your changes
@Danthar by chance I'm looking at the resizer implementation. It seems that if you create a custom router, you can use ActorRefRoutee to lookup this information: https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka/Routing/Resizer.cs#L245
Natan Vivo
@nvivo
I guess the way to do it then would be create a parent to intercept "are you busy" messages and the actor would ask the custom router directly
Arjen Smits
@Danthar
@aprooks a busy message based on actor idle time/last message processed would work. But I am not sure it fits my scenario. Would have to think about it some more.
Natan Vivo
@nvivo
fwiw, i did the same with actors directly and a simple "entry" record for each child
Arjen Smits
@Danthar
@nvivo a group-router-like actor could definitely be used to wrap the idle-monitoring behaviour.
Natan Vivo
@nvivo
basically created a class Entry { ActorRef Actor; bool Busy; }
and set the flags on request response. this of course depended on all answers going back to the actor I had
this model is so flexible there are many ways to do the same thing
Arjen Smits
@Danthar
Yup
Thats why I was asking if there is anything in Akka right now, that can be used to achieve the same thing. Without me having to manually implement it.
Brandon Wilhite
@JediMindtrick
Is there a way to allow an akka.net actor to interact with a remote akka (jvm) actor? Akka-jvm has a wire protocol, would this allow it?
Natan Vivo
@nvivo
not currently
Brandon Wilhite
@JediMindtrick
ok, so not currently. If we wanted to build such a thing, does anyone know if the wire protocol might be the enabling tech for it? OR is there really not any enabling tech (other than design off of http/tcp/whatever from the ground up)?
Arjen Smits
@Danthar
When you start talking about communicating between the CLR and JVM It suffers from the same problems as any remoting tech. The wire protocol is the least of your problems.
Brandon Wilhite
@JediMindtrick
Sure, there would be a lot of obstacles.
There's a lot of complexity there that would have to be handled. My thought was that possibly the Akka wire protocol was defined to help handle some of it....not really just worried about the transport here.
Arjen Smits
@Danthar
@Aaronontheweb would know alot more about this topic.
Brandon Wilhite
@JediMindtrick
k, thanks
Arjen Smits
@Danthar
He's the one who worked on Helios/Lighthouse and alot of the remoting stuff (afaik). So he is probably much better equipped to tell you what kind of cesspool your walking into ;)
Brandon Wilhite
@JediMindtrick
lol, y I'm sure...I'm not really contemplating this for any actual work project, more as a persistent itch I've had the last few years...just to see if it can be done
Natan Vivo
@nvivo
anything is possible, few things are worth the trouble
I believe if you want to communicate between 2 different systems, it's easier to build some http layer through json nowadays outside of akka and just use that
Brandon Wilhite
@JediMindtrick
and also...just because it can be done doesn't mean you should do it :)
Natan Vivo
@nvivo
yeah.. think about it, yo usually won't couple 2 applications made with different versions of .NET
even more with 2 applications made for different languages at that level
Brandon Wilhite
@JediMindtrick
don't get me wrong....I'm not advocating people should do what I'm asking about...I'm more just curious about this since the idea of rpc is kind of built into akka from the get-go
after all...if I'm sending a message to a remote actor, what should it matter what kind of runtime is running over there? But my experience with akka is limited and this is just something I've wondered about for awhile now.
i'd think supervision, deathwatch and probably other things would get pretty hairy
Natan Vivo
@nvivo
sure
from what I read here, one of the big problems would be endianess, as the protocol is binary and java and .net use different ways to encode these stuff