Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3989
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3992
Aaron Stannard
@Aaronontheweb
haha
rsinohara
@rsinohara
Still puzzled about why it worked when that test was run individually, but there you go... I've had this issue for days lol
Aaron Stannard
@Aaronontheweb
guess you just needed some "rubber duck debugging" for that one :p https://en.wikipedia.org/wiki/Rubber_duck_debugging
might have worked when 1 test at a time because this is a race condition
the actor will asynchronously receive those messages as part of the tell
rsinohara
@rsinohara
I just needed to read the code after a few days off it :)
Aaron Stannard
@Aaronontheweb
and the ignore messages is synchronous
so it was just coincidence that it worked at all - whereas when you ran the full suite you eventually hit a case where you lost the race
rsinohara
@rsinohara
That's why this test is the only one that had this issue, as others I have ignores use TestActors
Maciek Misztal
@mmisztal1980
@Aaronontheweb After a 3rd Become, I'm trying to do a Self.Tell(new Msg()) but that Msg is never received, even though the Receive<Msg>(...) is set in that Become(...) handler
rsinohara
@rsinohara
btw congrats Aaron, besides the nice work on akka.net, you're an amazing speaker
rsinohara
@rsinohara
Hmm, I cannot call methods on TestActor.UnderlyingActor... What is the recommended way to make a test actor become something, without having to go through all the state changes?
(Or is the only way to create a message handler just for this?)
Bartosz Sypytkowski
@Horusiath

@rsinohara think about this a little differently. Become essentially builds a state machine. C# await also builds a state machine:

DoSomething();
await DoSomethingAsync(); // in this continuation the behavior switches
DoSomethingElse();

How do you want to check if DoSomethingElse() has been called without calling first two methods before?

rsinohara
@rsinohara
@Horusiath I'm not sure what you mean. Suppose my actor goes S1->S2->S3. I want to test S3 behavior, without having to interact with the actor to make it follow nominal path from S1 to S3.
I just want to set that state, then test its behavior, not test the state change flow.
Bartosz Sypytkowski
@Horusiath
what I'm trying to say, is that's impossible unless you already have some start point, which allows you to omit are intermediate steps
just like you cannot execute only the last line of the method without going through every statement before
rsinohara
@rsinohara
Well I can create a message handler that will directly call the specific Become... but I'll be creating a handler just to accommodate tests - which I'd avoid unless there is no way
Bartosz Sypytkowski
@Horusiath
when writing tests for akka, I usually write the whole initialization code (if it's repeatable, make a separate method from it)
rsinohara
@rsinohara
If Underlying actor exposed methods, that would be as simples as calling a method that Becomes what I need for the test in question.
A hack would be to do it through a property setter/getter (ewww)
Bartosz Sypytkowski
@Horusiath
if I make a shortcut to test only the specific behavior without steps that I need to make on the way, then I'm not truly testing that behavior. Simply because the tested scenario is artificial and doesn't occur in reality
heh, testing only the behavior is something that's going to happen, when akka-typed goes out :P
rsinohara
@rsinohara
I get what you mean now
Maybe I should rethink my testing startegy
Is there any material on actor (unit) testing?
I'd love a book about that.
Bartosz Sypytkowski
@Horusiath
the biggest reference is akka repository - around 4000 examples ;P
rsinohara
@rsinohara
Aren't they too low level?
Bartosz Sypytkowski
@Horusiath
it depends, most of them are actually integration tests - using the testkit itself
rsinohara
@rsinohara
Interesting then. I'll take a look. Thanks :)
Jeff
@jpierson
Is there a way to create a ConsistentHashingGroup router where the hash id determined by the sender as opposed to something in each message?
On second thought, perhaps it would be better to have some other actor responsible for providing another actor for direct communication (routee) based on a consistent hash of the sender without using a router. Is this an existing pattern already that has a name? I'm running into this where I have interfaces between external services where I wanted ordered retry logic but don't want to force everything to be processed in serial, just in proper order based on the sender to keep the sender/receiver order guarantees.
Aaron Stannard
@Aaronontheweb
I think I'll be able to add the ability to log anything on the Scheduler that wasn't executed at the time it was shutdown
as part of some of these changes
Michael
@michaelsg
anyone have familiarity with the F# api? I have one nagging question about the implementation of pipe operator |!>.
Bartosz Sypytkowski
@Horusiath
@michaelsg what's up?
Michael
@michaelsg
Had a question about the implementation of the pipeTo (|!>) operator - how it's supposed to work. I gathered that it was supposed to be non-blocking but it uses Async.StartWithContinuations which starts the async on the current thread. I think it only work right for the things like in the examples of its use - that are already-running .net things wrapped in asyncs.
if I create an f# async - not just something wrapping a task or async pattern, it blocks.
Bartosz Sypytkowski
@Horusiath
what are you creating F# async for?
Michael
@michaelsg
to do background work :-) sorry. not trying to be cheeky. I don't know what you mean.
Bartosz Sypytkowski
@Horusiath
I'm just asking for the use case ;) If you're working with something that already starts an async, it should be good to go.
Michael
@michaelsg
so that's the thing. Async (the kind you make with async {}) aren't running when they are created. and starting one does not return an async - it returns unit.
Bartosz Sypytkowski
@Horusiath
yep, it may be a problem ;) Probably something to be fixed - can you set a github issue on that?
Michael
@michaelsg
async { do! Async.Sleep 50000.; return AMessageToSend("hello") } |!> mbx.Self
you agree that shouldn't block?
Corneliu
@corneliutusnea
guys, any guidance on deploying Akka cluster on Azure?
Maciek Misztal
@mmisztal1980
depends on what you need?
Corneliu
@corneliutusnea
anything to make my life easy-ier :smile: e.g. how do deploy lighthouse-es, experiences, dealing with azure vm virtual ips