These are chat archives for akkadotnet/akka.net

7th
Jun 2017
Zetanova
@Zetanova
Jun 07 2017 04:21
@Danthar Thank u for your answer. because i run in a problem with the datasource and the akka.persistence, I have for each boundary an actorsystem. all actorSystems are currently running in the same process / CLR. So i am asking myself, why it is not possible to resolve path's from an other actorsystem in the same process. Why is there an acorsystem Name ? With the actorsystem Name it should be possible for in-process routing and also to bind multiple actorsystem to the same transport. Is the actorsystem-name only a filler for the hostname of an URL and can be ignored?
Zetanova
@Zetanova
Jun 07 2017 06:01
If i start two actorsystems in the same process on the same port, there are no errors but, the process is listining on the same port twice Never saw it before.
explanse the socket behavior
Arjen Smits
@Danthar
Jun 07 2017 06:37

Once the second socket has successfully bound, the behavior for all sockets bound to that port is indeterminate

@Zetanova And that explains why i said that you would need some kind of hosting service that routes incoming messages/connections to the right process ;)

Zetanova
@Zetanova
Jun 07 2017 06:37
i have single process
Arjen Smits
@Danthar
Jun 07 2017 06:38
with process, i mean actorsystem
the name of the actorsystem is like a namespace
if you would give all actorsystems on your process, the same name, how would you know where to route a message if the address is exactly the same (because your using the same port as well).
Zetanova
@Zetanova
Jun 07 2017 06:39
it is not the same
Arjen Smits
@Danthar
Jun 07 2017 06:39
Well thats good, then you can differentiate.
Zetanova
@Zetanova
Jun 07 2017 06:40
but where to hook?
Arjen Smits
@Danthar
Jun 07 2017 06:40
Well there are 2 problems.
first, the default TCP transport is not made for this kind of behavior. Like i quoted, once a second socket is bound to the same port, the behavior for all sockets bound to that port becomes indeterminate. Which means that traffic incoming on that port, can be picked up by any, or all sockets
So communicating over tcp sockets, isn't going to work.
Like i said earlier and @Aaronontheweb hinted to as well. For this scenario, a NamedPipes Transport would be ideal
With Akka remote, you can configure multiple transports for the same actor system
so you can communicate between actorsystems on the same process via NamedPipes, but still have network connectivity using the TCP transport
Zetanova
@Zetanova
Jun 07 2017 06:45
why actorsystem sys1 cant resolve actorrefs of sys2 in the same process?
Arjen Smits
@Danthar
Jun 07 2017 06:46
It can. Thats not the problem. The problem is how to communicate with that system once you have
Zetanova
@Zetanova
Jun 07 2017 06:46
if actorsystem sys1 got a ActorRef as Sender from sys2
of course it is working
no it cant
Arjen Smits
@Danthar
Jun 07 2017 06:47
oh wait, your passing local actorrefs between them ?
Zetanova
@Zetanova
Jun 07 2017 06:47
currently yes
the can be local or remote (want to be transparent)
Arjen Smits
@Danthar
Jun 07 2017 06:47
haha i have no idea akka would behave in that scenario.
frankly im not surprised it causes problems
Zetanova
@Zetanova
Jun 07 2017 06:48
Context.ActorSelection(ev.Subscriber).ResolveOne() will then not work
what i am looking for
Arjen Smits
@Danthar
Jun 07 2017 06:48
if you debug the address of ev.subscriber what does it say ?
Zetanova
@Zetanova
Jun 07 2017 06:49
was a local address of the other actorsystem
Arjen Smits
@Danthar
Jun 07 2017 06:49
Exactly
because its a local adress
the resolves of your current actorsystem
assumes its a local actor
but it cannot find it
Zetanova
@Zetanova
Jun 07 2017 06:49
yes, who created the string?
Arjen Smits
@Danthar
Jun 07 2017 06:49
because A: its has a different actorsystem name, and B: the actor path probably does not even exist
in that local actors sytem
Zetanova
@Zetanova
Jun 07 2017 06:50
the current actorsystem
Arjen Smits
@Danthar
Jun 07 2017 06:50
That string was created by the actor system the actor actually lives in
The problem is the protocol segment
of that address
your actorsystem detects that its a local adress and attempts to resolve the actor locally
but it cant
because the actor does not live locally
thats why we are saying, you need a NamedPipes transport
because then the protocol spec would indicate something like this:
Zetanova
@Zetanova
Jun 07 2017 06:51
then i can just make remoting
Arjen Smits
@Danthar
Jun 07 2017 06:51
akka.namedpipes://etcetcetc
and the actorsystem detects its a remote actor, and uses the namedpipes transport to resolve the actorpath
Zetanova
@Zetanova
Jun 07 2017 06:52
i want to stay address trasnparent
Arjen Smits
@Danthar
Jun 07 2017 06:52
and directs communication through the transport
Zetanova
@Zetanova
Jun 07 2017 06:52
direct?
u mean serialized
Arjen Smits
@Danthar
Jun 07 2017 06:53
instead of sending the communications locally in the same actorsystem, it defers it to the transport and let that handle the communication
then your transport can do whatever it wants
Zetanova
@Zetanova
Jun 07 2017 06:53
when the message get serialized?
Arjen Smits
@Danthar
Jun 07 2017 06:54
im not sure if that happens immediatly. I think its purely the transports responsibility, but you'd have to check
Zetanova
@Zetanova
Jun 07 2017 06:54
couldnt find it
what i found from the doc's is that the EndpointWriter could pass the unseriliazed message direclty to the EndpointReader, but i didnt looked up in the source
Arjen Smits
@Danthar
Jun 07 2017 06:56
Why is it so important for you to prevent message serialisation ?
Zetanova
@Zetanova
Jun 07 2017 06:57
i have a 3th generic boundary context now
with an abstract message box
Arjen Smits
@Danthar
Jun 07 2017 06:58
So ?
Zetanova
@Zetanova
Jun 07 2017 06:58
when the message box is in the same process
why then to serilaize one more time ?
Arjen Smits
@Danthar
Jun 07 2017 06:59
So its purely an optimization
Zetanova
@Zetanova
Jun 07 2017 06:59
y
of course
Arjen Smits
@Danthar
Jun 07 2017 06:59
ok
Zetanova
@Zetanova
Jun 07 2017 06:59
or if somebody deployies to remote actors on the same system
Arjen Smits
@Danthar
Jun 07 2017 07:00
Why not host the message box locally, outside of an actor system
Zetanova
@Zetanova
Jun 07 2017 07:00
and they starting to talk to each other, will the message be serialized?
Arjen Smits
@Danthar
Jun 07 2017 07:00
and send a message containing the messagebox reference, to each local actorsystem so that they can use it
or write a class that coordinates access to that messagebox, and send each actorsystem a reference to that class
way simpler
Zetanova
@Zetanova
Jun 07 2017 07:01
yes, that is basicly what i did
but i dont know if the receiver is local or remote
what i am currnelty doing is to create this message box outside of the actorsystem
it has internaly the actorRef its own actor
then the ouside code then send with the help of this inbox to a target a message
so the target actorsystem gets the ActorRef of the messagebox-actor
Zetanova
@Zetanova
Jun 07 2017 07:06
now i want to persistent the subscription
i hit this limitation, that i just cant resolve the local actor address from different actorsystem in the same process
Arjen Smits
@Danthar
Jun 07 2017 07:09
Ah. Ok
Well that limitation is not something you can fix easily. The only way to.handle that. Is by using a transport specifiek address
So akka.net knows it needs to use the transport implementation to resolve and communicate with, the actor
Thats how the whole framework.is designed.
Zetanova
@Zetanova
Jun 07 2017 07:11
i will look into it in a later point in time
currently traing to get remoting work
"No transport is loaded for protocol: [akka], available protocols: [akka.tcp]"
could i write an own "akka" protocol trasnport ?
and make some static ImmutableList<ActorSystem> happen?
Arjen Smits
@Danthar
Jun 07 2017 07:16
Only one way to find out :)
Zetanova
@Zetanova
Jun 07 2017 07:24
with visual studio 2013 now change
need to update :)
Zetanova
@Zetanova
Jun 07 2017 09:09
maybe i am on the wrong path
if the subscriberRef should only be persisted
i need to serilize the actorRef and not to save the path
with: string id = Serialization.SerializedActorPath(theActorRef);
because the Sender is local but from a different actorsystem in the same process
ToStringWithAddress is not working
Zetanova
@Zetanova
Jun 07 2017 09:27
akka is trying to resolve the remoteRef with "akka://otherSys/ ..." and failes with the no trasnport is loaded for protocol: [akka]
what i can see from the source is that to implement an InPorcess Akka.Remote.Transport would be possible in some form, but the serialiazion would happen
before AssociationHandle.Write
Zetanova
@Zetanova
Jun 07 2017 10:10
All magic stuff is somehow not realy working to serialize and resolve local actorRef's from different actorSystems
Just made a static class where i register the actorSystems and resolve the actorRef on the correct name
Ismael Hamed
@ismaelhamed
Jun 07 2017 10:52
@Horusiath I just realized, the Context.Sender inside the callback of a Persist() becomes the journal actor when using the new BatchingJournal (this doesn't happen with previous journal). I haven't have the time to check whether this is actually a bug or I made a mistake while implementing the Oracle driver. But, anyhow, is it a good idea avoiding closing over the sender in the callback of a Persist?
Zetanova
@Zetanova
Jun 07 2017 10:56
@ismaelhamed think is a misstake, the sender should stay the same, would break my code instantly
Ismael Hamed
@ismaelhamed
Jun 07 2017 11:03
@Zetanova yep, but then again you have to be carefull when using async/await, so I thought maybe I should treat callbacks the same way
Zetanova
@Zetanova
Jun 07 2017 11:09
@ismaelhamed I tried async/await in the beginning of 2016. it was not a good idea, Better to lock or use PipeTo(Self, () => new messageComplete()). maybe with the new dispatcher is is working better
Zetanova
@Zetanova
Jun 07 2017 11:16
beside some problems with the asyncState lost and/or continue on the wrong thread
there is a issue with thread stealing from the dispatcher
some frameworks are using the calling thread for work and continue on a new thread
akka had or has problems with it
Zetanova
@Zetanova
Jun 07 2017 11:25
@Danthar resolved the problem with the in-process reouting with a static class where i just register the actorsystems

'
if (!ActorPath.TryParseAddress(actorPath, out address))
throw new UriFormatException();
if (!address.HasLocalScope)
throw new NotSupportedException();

return actorSystems.FirstOrDefault(n => n.Name == address.System);
'

working fine now
Arjen Smits
@Danthar
Jun 07 2017 11:47
:+1: hurray for simple solutions
Bartosz Sypytkowski
@Horusiath
Jun 07 2017 17:15
@ismaelhamed it's a bug indeed
Aaron Stannard
@Aaronontheweb
Jun 07 2017 17:16
yeah, definitely need to close over that @ismaelhamed
Aaron Stannard
@Aaronontheweb
Jun 07 2017 17:57
@ismaelhamed heh, @alexvaluyskiy just sent in a PR to fix it akkadotnet/akka.net#2735
Bert Lamb
@BertLamb
Jun 07 2017 20:13
@spankr I've made some updates to Akka.Persistence.EventStore got all but one test passing at the moment https://github.com/BertLamb/Akka.Persistence.EventStore
Aaron Stannard
@Aaronontheweb
Jun 07 2017 20:15
@BertLamb who is maintaining that plugin these days?
Bert Lamb
@BertLamb
Jun 07 2017 20:18
no one as far as I can tell
Bert Lamb
@BertLamb
Jun 07 2017 20:28
the weird bit is where my test is failing is here, which from what I can tell shouldn't be related to the Journal provider unless I'm missing something https://github.com/akkadotnet/akka.net/blob/v1.3/src/core/Akka.Persistence.TestKit/Journal/JournalSpec.cs#L241
ugh...I had publish-plugin-commands = off...whoops
Bert Lamb
@BertLamb
Jun 07 2017 20:41
one could argue that a unit test shouldn't be dependent on that setting
sadanlives14
@sadanlives14
Jun 07 2017 22:20
Hi, I have a SSIS package which run every night has WCF service tasks execute in sequence, I need to replace this(SSIS Scheduler) using akka.net. So wanted to know which Akka.net design pattern good for this use case. Appraciate for your help
Zetanova
@Zetanova
Jun 07 2017 23:00
@sadanlives14 u need an actor that acepts messages of kind work/task/step. The TaskMessages should include all information to execute the task. that can even be Props to create a unkown workerChild that executes the task/step. The main actor should have some behavior-states: Idle, Executing, Executed
In the Idle behavior on taskMessage, it should become "executing"
in the executing behavior it should process all messages beside the taskmessage, this message should be then stashed
after executing the actor should send ConfirmExecuted to itself Untash all messages from the Stash and become Executed
Zetanova
@Zetanova
Jun 07 2017 23:05
in the Executed behavior it should handle all messages beside taskMessage and ConfirmExecuted as Unhandled
taskMessages it should stash again
and on ConfirmExecuted it should become idle and unstash all messages from the tash
sadanlives14
@sadanlives14
Jun 07 2017 23:07
@Zetanova Thanks for info : Do you have and sample code or like...will help lot - Thank you!!
Zetanova
@Zetanova
Jun 07 2017 23:07
not with a lot own DSL
the main idea is to stash the taskMessages if the current one is not finished
and when the task finishes to send a complete message to itself
and on arrival of this message to untash all messages from the Stash and become from executing to the initiale behavior (idle)
the 3th behavior "Executed" is only for safty and debug
Zetanova
@Zetanova
Jun 07 2017 23:13
if some rough responses are coming from somewhere