Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 14 21:02
    Aaronontheweb synchronize #3975
  • Oct 14 21:02
    Aaronontheweb opened #3975
  • Oct 14 20:11
    IgorFedchenko commented #3973
  • Oct 14 20:10
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 19:42
    IgorFedchenko edited #3973
  • Oct 14 18:08
    Aaronontheweb commented #3937
  • Oct 14 17:27
    Aaronontheweb commented #90
  • Oct 14 17:26
    Aaronontheweb commented #90
  • Oct 14 17:25
    Aaronontheweb assigned #90
  • Oct 14 17:16

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • Oct 14 17:16
    Aaronontheweb closed #3974
  • Oct 14 17:16
    Aaronontheweb milestoned #3974
  • Oct 14 16:05
    jackowild opened #90
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
Roger Johansson
@rogeralsing
So some opt in/opt out must be in place
Aaron Stannard
@Aaronontheweb
got it
ok, so not a good default then?
Roger Johansson
@rogeralsing
Probably not, not sure whats worth the most, ease of use or speed? Then make the least worth opt in
Aaron Stannard
@Aaronontheweb
I would make it an opt-in thing
if someone really super want async and await
they can deploy actors with that dispatcher
otherwise, we should let them get the high performance option by default
Roger Johansson
@rogeralsing
Exactly. Ill clean it up and publish in my repo and we can experiment with it
Aaron Stannard
@Aaronontheweb
do you want to make it a contrib module or integrated into core?
contrib/dispatchers
Roger Johansson
@rogeralsing
It could just aswell be integrated? Its just a dispatcher. Doesnt affect the rest of the system
Aaron Stannard
@Aaronontheweb
I think that's fine
might as well, right?
Roger Johansson
@rogeralsing
Yes, lets make it experimental and see what the community say
Aaron Stannard
@Aaronontheweb
I agree
I think that teaching people to treat Task instances as messages sources (with PipeTo) is the "right way" to do async inside an actor
but I can't argue with giving developers the option to do it a different way if we can support it :smile:
especially if it gives feature parity with Orleans, because you know that'll come up every now and then :p
Roger Johansson
@rogeralsing
Yepp
The good news, they only have this option, so they can never go fast
Aaron Stannard
@Aaronontheweb
yeah, I think it's good to have knobs and dials
but the out of the box option should be the common case / low overhead one
brb, think I need to restart my machine
Roger Johansson
@rogeralsing
I benchmarked the async await support, we drop ca 50% throughput in the ping pong example, not as bad as I thought, but still a lot, in real world scenarios, it will be way less...
Aaron Stannard
@Aaronontheweb
that reminds me @rogeralsing, do we still have a to-do item for configurable named dispatchers and all that jazz?
or is that already implemented?
Roger Johansson
@rogeralsing
Not sure how complete that support is, we do have named dispatchers and they can be configured with throughput settings etc. but I dont think we support any extra config except from that
Aaron Stannard
@Aaronontheweb
there are a few places within Akka.Remote and Akka.Cluster that need them, marked with todo:
if that stuff is good to go now then I might go back through and start tidying those up
since I'm going to be neck-deep in that stuff for the next couple of weeks
Roger Johansson
@rogeralsing
what do they need? just different dispatchers?
Aaron Stannard
@Aaronontheweb
yeah, basically the /system/ level actors for those packages that are really chatty run on their own dispatchers
mostly it's for stuff like heartbeats and cluster gossip
right now they just run on the default dispatcher
Roger Johansson
@rogeralsing
ah, yes that should work just fine. just set a different dispatcher and make the dispatcher handle its own threads or whatever
Aaron Stannard
@Aaronontheweb
cool, I'll do that - if the named dispatcher stuff works then that should be easy
Aaron Stannard
@Aaronontheweb
beautiful
ok great, I'll create this as an issue
@rogeralsing in your PR, did you update the version of XUnit?
Roger Johansson
@rogeralsing
that is using the nuget deployed vs runner.. not sure if that is the way to go(?) the xunit 2.0 runner will not deployed as an addon but just as a nuget project reference for the test projects
Aaron Stannard
@Aaronontheweb
ah, here's the reason why I ask: #601
might be hitting an XUnit bug that's fixed in the latest RC
we're currently using latest stable
David Smith
@smalldave
we've been using xunit 2+ for a while now. running tests concurrently is a very big plus for us. however tooling like resharper test runner is a bit behind. also had a number of our tests start to hang when we moved to latest release candidate so we rolled back to previous version we were using. in short best to check that positives outweigh cons before upgrading
Aaron Stannard
@Aaronontheweb
@avoxm @jcwrequests just saw this today from MSFT - might be able to use it for buffer recycling inside Helios for decreased GC pressure: http://www.philosophicalgeek.com/2015/02/06/announcing-microsoft-io-recycablememorystream/
Roger Johansson
@rogeralsing
:+1:
Bartosz Sypytkowski
@Horusiath
I've just rebased latest version of akka dev and found 3 failing (repeatedly) tests in Akka.MultiNodeTestRunner.Shared.Tests.ParsingSpec
Aaron Stannard
@Aaronontheweb
@Horusiath make any changes to the built in "ToString" for log messages?