Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • 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
Natan Vivo
@nvivo
you should leave the default or specify Suspend
are you using ReceiveActor?
Daniel Ferreira Monteiro Alves
@danfma
yes
I will write one example here, just a moment
Natan Vivo
@nvivo
just do Receive<Foo>(async foo => { .. })
the default behavior is Suspend already
Roger Johansson
@rogeralsing
Btw async await is broken in nuget 1.0 package
Natan Vivo
@nvivo
oh, right!
Andrew Skotzko
@skotzko
but fix coming next week
in 1.0.1
Daniel Ferreira Monteiro Alves
@danfma
ahhhh
Natan Vivo
@nvivo
@danfma I'm Brazilian
Daniel Ferreira Monteiro Alves
@danfma
:D
me too
and good to say that was not a problem with me this time
:D
public class JobExecutor : ReceiveActor
    {
        private readonly Application _application;
        private bool _working = false;

        public JobExecutor(Application application)
        {
            _application = application;

            Receive<BeginWork>(AsyncBehavior.Reentrant, _ => _application.ExecuteInScope(() => OnBeginWork()));
        }

        private async Task OnBeginWork()
        {
            if (_working)
            {
                Console.WriteLine("Executando trabalho ainda {0}", Thread.CurrentThread.ManagedThreadId);
                return;
            }

            _working = true;

            Console.WriteLine("Iniciando trabalho {0}", Thread.CurrentThread.ManagedThreadId);
            //Thread.Sleep(8000);
            await Task.Delay(10000);
            Console.WriteLine("Finalizando trabalho {0}", Thread.CurrentThread.ManagedThreadId);

            _working = false;
        }
    }
Natan Vivo
@nvivo
Reentrant means exactly that messages will be processed during task awaits
you want the non-reentrant behavior
Andrew Skotzko
@skotzko
yeah you want the suspend behavior
Daniel Ferreira Monteiro Alves
@danfma
if I use the suspend the message will be processed only one time
Natan Vivo
@nvivo
Yes, and that's the default, you don't need to provide an argument
Andrew Skotzko
@skotzko
Daniel Ferreira Monteiro Alves
@danfma
ok I will check
Natan Vivo
@nvivo
out of curiosity, what is that Application you have there? Are you executing that code somewhere else?
Daniel Ferreira Monteiro Alves
@danfma
I created an instance of my app, which starts the windsor and others services, so that application is where my services are
Natan Vivo
@nvivo
You can use DI with akka, there are some docs with that
and as a general rule, you should never touch actor state from threads other than what the actor is running on
Daniel Ferreira Monteiro Alves
@danfma
yes, I know, I will check that too, I just want to use quickly here to test
Natan Vivo
@nvivo
right
Daniel Ferreira Monteiro Alves
@danfma
that's the problem
Natan Vivo
@nvivo
In essense, you should have only Receive<BeginWork>(_ => OnBeginWork())); and get your services in some other way, as dependencies for example
Daniel Ferreira Monteiro Alves
@danfma
yes
but in this case, some services lives only that the scope defined by that call, that's why I used that.
it just wraps the call with a scope
Daniel Ferreira Monteiro Alves
@danfma
@skotzko Thanks for the site! I already saw part of it before, but I will read the rest! :D
Andrew Skotzko
@skotzko
sure thing
Brandon Wilhite
@JediMindtrick
@Danthar That's why I had in parens (pick your transport)...going that way you have a number of options. Rabbit would be a good choice too, imo.
Brandon Wilhite
@JediMindtrick
@Aaronontheweb Thanks for the story :) ...y, I knew as soon as the other guy mentioned endianness there was a problem. Akka.io wrapper seems like a suitable strategy.
Daniel Ferreira Monteiro Alves
@danfma
@skotzko Thanks for that link! I read it to the end here and now I can see what was happening! :)
Andrew Skotzko
@skotzko
@danfma you’re welcome :)
Natan Vivo
@nvivo
In Pigeon.conf, are these settings for "default-dispatcher" valid also for other dispatchers?
Bartosz Sypytkowski
@Horusiath
each dispatcher may use it's own keys, but type and throughput are common
Natan Vivo
@nvivo
what about shutdown-timeout?
Sean Gilliam
@sean-gilliam
Maybe I'm missing something but lulz
    /// <summary>
    /// XML (omg not XML!) implementation of the <see cref="IPersistentTestRunStore"/>
    /// </summary>
    public class JsonPersistentTestRunStore : IPersistentTestRunStore
Roger Johansson
@rogeralsing
And deadline-time
Aaron Stannard
@Aaronontheweb
@sean-gilliam lol yeah
my bad on that one
was going to go with XML for the reporting tools on the multinode test runner so it felt all enterprisey and browser-viewable
then I got really lazy