@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?
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
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 ;)
i have single process
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).
it is not the same
Well thats good, then you can differentiate.
but where to hook?
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
why actorsystem sys1 cant resolve actorrefs of sys2 in the same process?
It can. Thats not the problem. The problem is how to communicate with that system once you have
if actorsystem sys1 got a ActorRef as Sender from sys2
of course it is working
no it cant
oh wait, your passing local actorrefs between them ?
currently yes
the can be local or remote (want to be transparent)
haha i have no idea akka would behave in that scenario.
frankly im not surprised it causes problems
Context.ActorSelection(ev.Subscriber).ResolveOne() will then not work
what i am looking for
if you debug the address of
ev.subscriber what does it say ?
was a local address of the other actorsystem
Exactly
because its a local adress
the resolves of your current actorsystem
assumes its a local actor
but it cannot find it
yes, who created the string?
because A: its has a different actorsystem name, and B: the actor path probably does not even exist
in that local actors sytem
the current actorsystem
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:
then i can just make remoting
akka.namedpipes://etcetcetc
and the actorsystem detects its a remote actor, and uses the namedpipes transport to resolve the actorpath
i want to stay address trasnparent
and directs communication through the transport
direct?
u mean serialized
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
when the message get serialized?
im not sure if that happens immediatly. I think its purely the transports responsibility, but you'd have to check
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
Why is it so important for you to prevent message serialisation ?
i have a 3th generic boundary context now
with an abstract message box
So ?
when the message box is in the same process
why then to serilaize one more time ?
So its purely an optimization
y
of course
ok
or if somebody deployies to remote actors on the same system
Why not host the message box locally, outside of an actor system
and they starting to talk to each other, will the message be serialized?
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
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
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
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
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.
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?
Only one way to find out :)
with visual studio 2013 now change
need to update :)
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
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
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
@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?
@ismaelhamed think is a misstake, the sender should stay the same, would break my code instantly
@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
@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
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
@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
:+1: hurray for simple solutions
@ismaelhamed it's a bug indeed
yeah, definitely need to close over that @ismaelhamed
@ismaelhamed heh, @alexvaluyskiy just sent in a PR to fix it akkadotnet/akka.net#2735
@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
@BertLamb who is maintaining that plugin these days?
no one as far as I can tell
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
one could argue that a unit test shouldn't be dependent on that setting
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
@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
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
@Zetanova Thanks for info : Do you have and sample code or like...will help lot - Thank you!!
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
if some rough responses are coming from somewhere