These are chat archives for akkadotnet/akka.net

30th
Sep 2016
qwoz
@qwoz
Sep 30 2016 01:45
@DamianReeves https://letsencrypt.org/
Peter Bergman
@peter-bannerflow
Sep 30 2016 06:25
@raskolnikoov Not sure if there is any built in way but what about a ScheduleTellOnce to Self and then schedule a new one with random delay when receiving the message
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:04
Hi guys, got a short question regarding DI. I see that the DI documentation is about injecting non-actor references like IService. What about IActorRef? is there a way or it was on purpose?
Arjen Smits
@Danthar
Sep 30 2016 07:08
@maxcherednik DI is not meant to inject IActorRefs
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:18
aha... I see. Was there a specific reason? What to do?
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:24
I very new to the actor model - trying to get used to. So currently I am at the moment where I am asking myself is this guy actually a child of this actor? If it is, then if the parent has the issue, then his kid will be restarted as well, all the state of the kid going to be lost. Which brings me to the idea that this actor is not actually a kid, it's just another service with it's own life cycle and I definitely don't want it to be restarted due to other actor's issue. So my decision is to inject it as IActorRef. Am I correct at this point?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:29
@maxcherednik yes
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:31
so do I inject manually?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:34
I would say it's a bad idea to use DI with actors, but if you need and cannot touch the actor's constructor, you can always pass IActorRef in some message
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:38
ParentActor(IActorRef service, IService anotherService) - the constructor looks like this. So I am slightly confused.
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:40
so you can either Props.Create(() => new ParentActor(serviceRef, new Service()) or change constructor to ParentActor(IService) and pass IActorRef in the separate message to the parent
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:42
ah, right. The first one fits I guess. This is a very high level actor, so I guess I can do this manually.
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:48
May I ask another question please. It's regarding the message delivery guarantees - I've read all the documentation, but there is still one thing which annoys me. Just want to hear a confirmation:) Let's say I have request-response actor, and the corresponding client of this actor. So the client sends the message - GetNewItem() and then it expects to receive the message HereIsYourItem. Do I always need to have the logic in the Client actor, which does the resend logic in case of message delivery failure?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:53
by default communication uses at-most-once-delivery semantics. This way your actor logic doesn't need to be idempotent.
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:53
so this means I have to do this all the time, right?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:54
On the contraty: imagine having some CreateItem request that will make some retries. What if actor on the other end acutally have created an item, but confirmation has not reach back to the caller? It will retry sending a message, creating a second item
Maxim Cherednik
@maxcherednik
Sep 30 2016 07:55
yeah in this case I have to have an ID - lets say Guid
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 07:59
depending on how much do you need it you can:
  1. Put this on the user - just like trying to go on a web site doesn't guarantee that you will receive a content. What user does then? Refreshes a site again.
  2. Put some message queue in front of actor system i.e. RabbitMQ or Azure Service Bus. This is often case for important messages that shouldn't be lost.
  3. Use AtLeastOnceDeliveryActor from Akka.Persistence module - it can redeliver messages until confirmed. You can set it in front of your communication chain.
Keep in mind that using higher delivery guarantees will slow down the message throughput of your actor system
Maxim Cherednik
@maxcherednik
Sep 30 2016 08:04
I've read and article recently about the error handling - they say that you should almost never catch the exception - let it fail. Imagine the example I mention. So I do send request, then the Child Actor Failed with some exception and never managed to send the Response. I've got 2 options here. 1. I don't catch anything and fully rely on the resend logic. 2. I do catch general exception(I don't like it) and I send back FailedMessage, so that Client could react faster
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 08:06
you can also use timeout and wait for it to occur
Maxim Cherednik
@maxcherednik
Sep 30 2016 08:06
yeah, that's my option number 1 I guess
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 08:07
but on the first place keep in mind that exception is not the same as business logic error - I know that many devs use exceptions for things like validation logic etc., which is a bad case here
Maxim Cherednik
@maxcherednik
Sep 30 2016 08:07
cause without Fail message I can't be sure if it's slow or failed
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 08:09
you've almost quoted one of the points about distributed programmming ;) "in distributed system often you cannot tell the difference between slow and failing server"
but in general you can check for the exception type (i.e. TimeoutException)
Maxim Cherednik
@maxcherednik
Sep 30 2016 08:10
so I guess there is no single truth here- it depends on my requirements. Having extra Fail message will make it faster to react, but more complicated logic and the opposite
Damian Reeves
@DamianReeves
Sep 30 2016 11:12
If I want to support message encryption and/or signing in my system where is the best place to implement this concern
Bart de Boer
@boekabart
Sep 30 2016 12:27
Encryption within akka (between remoting peers) will be in 1.5 (TLS); otherwise, in your bridge towards the world (eg. your WebApi API). Bottom line is that without TLS (current situation), akka.remote connections are not secured, so use them on private subnets only or provide proper firewalling
Damian Reeves
@DamianReeves
Sep 30 2016 12:52
That's what I see the current state as being, so I guess I'm wondering how is everyone using cluster in Azure securing their messages? And this is probably my relative inexperience with Azure speaking here, but if I have 2 different VMs at somepoint I have no guarantee that the traffic between nodes in my cluster is safe, do I?
It would seem, absent of TLS, I need to do all my inter-node communication via a REST gateway or something HTTPS, but this is not what I hear in this room as being typical.
Bart de Boer
@boekabart
Sep 30 2016 13:16
No azure expert but doesn't azure provide you with a private subnet as well as public interfaces?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 13:18
@DamianReeves I guess the easiest place to encrypt your messages would be to create custom serializer, which will encrypt/decrypt byte stream of messages
Damian Reeves
@DamianReeves
Sep 30 2016 13:19
@boekabart Yeah they do. Also not being an Azure expert, I've never set one up. I guess I've got to dig into that. I guess in theory it shouldn't be much different than multiple machines on a VPN talking to each other.
@Horusiath okay so if I went that method that's I guess the best hook. I've used various service bus libraries i.e. MassTransit, Rebus, EasyNetQ and they all had encryption as this thing I can add around my messages wasn't sure if there was an equivalent like
akka {
   actor {
      encryption {
          encrypt-messages = true
          encryption-key = abcdefghijklmnop
      }
   }
}
Ivan R. Perez
@irperez
Sep 30 2016 19:06
Anyone have any idea why some unit tests are always skipped? I'm not talking about t he ones that have the attribute to skip, (Skip="TODO"), rather, these are normal MultiNodeFacts test methods, yet they are getting skipped consistently.
blob
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 19:37
@irperez there are different reasons, sometimes tests are not finished, sometime they have some racy behavior
Ivan R. Perez
@irperez
Sep 30 2016 19:39
@Horusiath The ones I'm having issues with are the Akka.Cluster.Tools.Tests.MultiNode tests. I don't see any reason to be skipped. I even ran the profiler and the debugger and no code is getting called. Its seeing the MultiFact attribute and its skipping the test from there. But the attribute itself does not call for the test to be skipped. Is there something I'm missing? I'm new to xunit testing.
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 19:40
they are not called from xunit, there is a separate multinode test runner executable for them
Ivan R. Perez
@irperez
Sep 30 2016 19:41
So what would trigger a skip?
Bartosz Sypytkowski
@Horusiath
Sep 30 2016 19:44
sorry, I didn't get your issue at first ;)
I have no idea
Ivan R. Perez
@irperez
Sep 30 2016 19:45
So if we look at the call stack here (not necessarily in order), you can see no test code is actually running, just attribute code.
blob
TonyLo1
@TonyLo1
Sep 30 2016 20:08
I am contemplating creating a BoundedPriorityMailbox where the lowest priority messages are discarded when the mailbox reaches a specified fixed capacity. If this already exists then pointers would be appreciated, otherwise is this a bad idea?
Ivan R. Perez
@irperez
Sep 30 2016 20:21
The only pattern I can see is that all "MultiNode" tests are being skipped. Is there something in the core MultiNode test framework that causes these tests to not be supported?
Ivan R. Perez
@irperez
Sep 30 2016 21:01
Ok, so digging into the MultiNode testkit code, it seems to be an issue with detecting if its a multinode test runner executing the code or not. And the logic to determine this seems to be off with my environment. I'm using VStudio 2015.
Ivan R. Perez
@irperez
Sep 30 2016 21:07
I see the problem. MultiNode test runner does not run within vstudio. My bad.
simonpetty
@simonpetty
Sep 30 2016 21:34
hi guys. i have what seems like a simple Streams question. I hope someone can help
I'm trying to figure out how best to split a source of records into 2 paths - basically valid and invalid
i've seen Where and WhereNot, but this seems to force me to check things twice. Is there something i'm missing?
Marc Piechura
@marcpiechura
Sep 30 2016 21:35
GroupBy should work
simonpetty
@simonpetty
Sep 30 2016 21:35
There's a lot of logic involved in deciding whether something is valid, and after that if it is, it will go through a transformation step
Aha
ok. i guess i imagine that running over a number of results linq style
cheers
Marc Piechura
@marcpiechura
Sep 30 2016 21:37
Np
simonpetty
@simonpetty
Sep 30 2016 23:28
still a bit stuck with this. so with a variable stored after calling GroupBy i can create two separate SubFlows each To a specific Sink
how do i then create a runnable graph?
a little lost as to what adding something to the GraphDsl builder actually does
back to trial and error getting something to compile - which is good from an API perspective, as it tells me i'm on the right/wrong path...but