These are chat archives for akkadotnet/akka.net

6th
Jun 2017
Zetanova
@Zetanova
Jun 06 2017 07:59
Hi, does somebody know if akka.Remote can resolve ActorPath's from different ActorSystem's running in the same CLR without serializing the messages? Basicly just send them in-memory when the ActorSystem's have the same transport address . And it is even possible to bind multiple ActorSystem's to the same tcp port?
Ivan Dorna
@dorvan
Jun 06 2017 08:25
@Danthar thanks to follow our project
Arjen Smits
@Danthar
Jun 06 2017 08:53
@Zetanova You can bind multiple actorsystems on the same tcp port, as long as its on a different ip :P. Its not possible to do that on the same machine. That would require some kind of intermediary hosting process that knows where to route incoming messages. Like the WAS does for WCF services.
Akka.Remote can resolve ActorPath's from different ActorSystems, no problem. However once you start sending messages through the remoting layer, it will be serialized.
Akka.Remote is designed for the use-case of interprocess communications. Therefore there is no option to not serialize a message when sending it via akka.remote.
You might be able to implement your own transport that does named pipes or something. That would speed things up. However im not sure how much level of control, implementing your own transport, gives you, in terms of serialization.
As in, im not sure if it allows you to circumvent serialization alltogether.
Marc Piechura
@marcpiechura
Jun 06 2017 13:30
Zufällig jemand von I-Solutions aus Bochum anwesend ? :smile:
Stephen Newman
@goodisontoffee
Jun 06 2017 13:34
Hey guys, do ReceivePersistentActors do anything different in the context of TestKit. I have a test which was working fine - sends a message to a ReceiveActor which was working fine BEFORE I made the actor a ReceivePersistentActor and changed Receive to Command. The test currently just checks to see if some internal state (via UnderlyingActor) is being set, unless I Fish for a message the test fails which makes me think that there is a difference in the threading behaviour.
Aaron Stannard
@Aaronontheweb
Jun 06 2017 16:22
Hi, does somebody know if akka.Remote can resolve ActorPath's from different ActorSystem's running in the same CLR without serializing the messages?
@Zetanova we'd have to use a transport of some kind to send messages
IMHO, this is an interesting use case for a NamedPipeTransport
being able to use that to do IPC on the same machine
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 17:18
@Silv3rcircl3 I think I'll skip FileSinkSpec for now and port the other PRs first
Marc Piechura
@marcpiechura
Jun 06 2017 17:27
Sure thing, but the third one contains also some code of the FileAPI :) but no problem if it doesn't work, I can implement them later too and ping you once I found some other stuff
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 17:29
I'll do the easier ones first to spare some of my brain cells, I still have to deal with a quirky OIDC server code at work, don't want to burn myself out XD
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 17:42
I take it there's no direct replacement for NonFatal in C#?
Marc Piechura
@marcpiechura
Jun 06 2017 17:43
Yup, simple Catch(Exception ex)
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 17:56
for akka/akka#22647, we don't have a LazySource class in Sources.cs
should I port the whole class?
Marc Piechura
@marcpiechura
Jun 06 2017 17:59
I've already done it, but it's not merged yet, sorry haven't seen that you need it for the PR
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 18:00
(y) thanks :)
this one ^^
you could rebase your local branch on my PR
sorry, haven't see that you need those changes
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 18:02
no problem :+1:
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 20:24
can I use async lambda in AssertAllStagesStopped, or should I use Task.Wait?
Marc Piechura
@marcpiechura
Jun 06 2017 20:26
Task.Wait, I don't think we have a async overload
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 20:26
right-o
task.Invoking(t => t.Wait(TimeSpan.FromSeconds(1))).ShouldThrow<TestException>()?
or should I check the task.Exception value instead?
                task.Wait(TimeSpan.FromSeconds(1));

                task.IsFaulted.ShouldBe(true);
                task.Exception.ShouldNotBe(null);
                task.Exception?.InnerException.ShouldBe(matFail);
Bartosz Sypytkowski
@Horusiath
Jun 06 2017 20:46
@Arkatufus I don't think we have any rule here for that, but I'd check for task.IsFaulted + task.Exception
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 20:47
alright, thanks
Gregorius Soedharmo
@Arkatufus
Jun 06 2017 21:34
I think I re-based my branch incorrectly... can someone check akkadotnet/akka.net#2731 and check? :worried: