Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 15 22:35
    Aaronontheweb commented #4032
  • Nov 15 20:26
    IgorFedchenko synchronize #4032
  • Nov 15 20:24
    IgorFedchenko commented #4032
  • Nov 15 20:06
    IgorFedchenko synchronize #4032
  • Nov 15 19:49
    IgorFedchenko synchronize #4032
  • Nov 15 19:32
    IgorFedchenko synchronize #4032
  • Nov 15 19:31
    IgorFedchenko commented #4032
  • Nov 15 18:49
    IgorFedchenko synchronize #4032
  • Nov 15 18:48
    IgorFedchenko synchronize #4032
  • Nov 15 18:47
    IgorFedchenko commented #4032
  • Nov 15 18:42
    IgorFedchenko commented #4032
  • Nov 15 18:41
    Aaronontheweb commented #4032
  • Nov 15 18:38
    IgorFedchenko commented #4032
  • Nov 15 18:37
    IgorFedchenko synchronize #4032
  • Nov 15 18:32
    IgorFedchenko commented #4032
  • Nov 15 18:30
    IgorFedchenko commented #4022
  • Nov 15 18:30
    IgorFedchenko synchronize #4022
  • Nov 15 18:26
    Aaronontheweb synchronize #4032
  • Nov 15 18:25
    dependabot-preview[bot] commented #4039
  • Nov 15 18:25

    dependabot-preview[bot] on nuget

    (compare)

Damian Reeves
@DamianReeves
across VMs
Web app on 1 VM... worker(s) on another
qwoz
@qwoz
TLS won't solve the problem of authentication; it would only ensure that messages are transported securely, even if the message originated from an unauthorized source (a non-coordinator). Can you make authentication part of the protocol? The message from the coordinator could use HMAC that the worker could validate and reject the message if the message doesn't check out.
Something akin to https://jwt.io/
Damian Reeves
@DamianReeves
Ok. I see. And Akka does nothing special to inject Claims into message pipelines like ASP.NET would for example
Is this kind of behavior typically handled at the Actor level... i.e. coordinator or is inheritance or processing pipelines the way it is usually handled?
Bartosz Sypytkowski
@Horusiath
@DamianReeves if you need some kind of extra behavior to be applied on any/choosen message kinds, you can override AroundReceive method of an actor - it's a hook, that gets called before Receive itself will occur
Damian Reeves
@DamianReeves
ok... cool thanks. Signing with something like a JWT token amounts to putting an envelope around outbound messages... is this typically handled by people per message or do I somehow hook into an Akka system message? (I'm just trying to avoid reimplementing the wheel and I can't be the first person to need this)
Bartosz Sypytkowski
@Horusiath
I would do that by wrapping custom message i.e. actorRef.Tell(new Authenticate(credentials, actualMessage)) and then unwrap and authorize it in AroundReceive - if auth fails, send back authentication failure. If it passes - unwrap the nested message and send in to actual receive message.
this way while message needs to be enveloped with Authenticate to be send with tell, but on the actor side it's actually transparent
Damian Reeves
@DamianReeves
sounds straightforward and clean... thanks
Aaron Stannard
@Aaronontheweb
@Horusiath @DamianReeves nope, neither supports TLS right now
1.5 will though
Daniel D'Agostino
@dandago2_twitter
hi guys, when you Persist(), is there any mechanism that gives you the sequence number you just saved?
Vagif Abilov
@object
Regarding Akka.Quartz.Actor: it would be great to publish a Nuget package for it.
Bartosz Sypytkowski
@Horusiath
@dandago2_twitter persistent actor itself has property LastSequenceNr
Maciek Misztal
@mmisztal1980
is anyone aware of a potential situation when Become(...) would make the actor unresponsive?
rsinohara
@rsinohara
Hello everyone. Can someone help me? My IgnoreMessages() do not work when I run every test I have, but it works when I run just that one test.
I am recreating everything on the setup before each test.
Aaron Stannard
@Aaronontheweb
@rsinohara you're using the Akka.NET TestKit and which implementation of it?
rsinohara
@rsinohara
nunit
this behavior is consistent
Aaron Stannard
@Aaronontheweb
if you're using the built-in mechanics there
and not reinventing the wheel
we guarantee that you start with a clean actorsystem each time
so this shouldn't be able to happen
@mmisztal1980 no, I'm not
rsinohara
@rsinohara
Yes, I recreate every TestProbe, props and actors on [Setup]
If I run that test + any other one, it fails (because it doesn't ignore that message)
_actor.Tell(new GameActor.NewGameMessage(new List<PlayerData>() { _userData1, _userData2 }));

            _userActorProbe1.IgnoreMessages(m=> m is UserActor.WelcomeToGameMessage);
            _userActorProbe2.IgnoreMessages(m => m is UserActor.WelcomeToGameMessage);

            _userActorProbe1.ExpectMsg<UserActor.GameInitializedMessage>();
            _userActorProbe2.ExpectMsg<UserActor.GameInitializedMessage>();
wait. Should my IgnoreMsgs be before .Tell?
Aaron Stannard
@Aaronontheweb
if the tell generates the messages that need to be ignored
then yep
rsinohara
@rsinohara
I just did that and it works... why on earth did I have them after?
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.