I was following the akka-in-action code-base remoting (https://github.com/RayRoestenburg/akka-in-action/tree/master/chapter-remoting). In the example, it explains remoting with sender actor and a receiver actor. Both the actors are started separately (via separate Main) and they are able to communicate as explained (Note:- both the actors are part of same code base).
I wanted to see how it behaves if the sender actor is part of a different project(independent code base). I created a Play web-app which sends a message to the above mentioned receiver actor upon getting a POST call thru some rest client (I used Postman).
What I observed is that, even though the message sent (a Case Class) is available in both the sender and receiver code base, the receiver complains a class not found error (its not able to understand the Case Class object that I sent from sender)
Is it an expected behavior that, if remoting has to work, the distributed actors should share same code-base?
Moving to Kryo/Chill will partially solve your problem, as long as you use the same exact version of Akka underneath. These binary serialization formats are inherently fragile. Avro does a better job at solving lifecycle issues of binary serialization; but alas, I have never seen Avro used as for serialization in Akka.
Related
I have an existing akka application built on socko websockets. Communication with the sockets takes place inside a single actor and messages both leaving and entering the actor (incoming and outgoing messages, respectively) are labelled with the socket id, which is a first class property of a socko websocket (in socko a connection request arrives labelled with the id, and all the lifecycle transitions such as handshaking, disconnection, incoming frames etc. are similarly labelled)
I'd like to reimplement this single actor using akka-http (socko is more-or-less abandonware these days, for obvious reasons) but it's not straightforward because the two libraries are conceptually very different; akka-http hides the lower level details of the handshaking, disconnection etc, simply sending whichever actor was bound to the http server an UpgradeToWebsocket request header. The header object contains a method that takes a materialized Flow as a handler for all messages exchanged with the client.
So far, so good; I am able to receive messages on the web socket and reply them directly. The official examples all assume some kind of stateless request-reply model, so I'm struggling with understanding how to make the next step to assigning a label to the materialized flow, managing its lifecycle and connection state (I need to inform other actors in the application when a connection is dropped by a client, as well as label the messages.)
The alternative (remodelling the whole application using akka-streams) is far too big a job, so any advice about how to keep track of the sockets would be much appreciated.
To interface with an existing actor-based system, you should look at Source.actorRef and Sink.actorRef. Source.actorRef creates an ActorRef that you can send messages to, and Sink.actorRef allows you to process the incoming messages using an actor and also to detect closing of the websocket.
To connect the actor created by Source.actorRef to the existing long-lived actor, use Flow#mapMaterializedValue. This would also be a good place to assign an unique id for a socket connection.
This answer to a related question might get you started.
One thing to be aware of. The current websocket implementation does not close the server to client flow when the client to server flow is closed using a websocket close message. There is an issue open to implement this, but until it is implemented you have to do this yourself. For example by having something like this in your protocol stack.
The answer from Rüdiger Klaehn was a useful starting point, thanks!
In the end I went with ActorPublisher after reading another question here (Pushing messages via web sockets with akka http).
The key thing is that the Flow is 'materialized' somewhere under the hood of akka-http, so you need to pass into UpgradeToWebSocket.handleMessagesWithSinkSource a Source/Sink pair that already know about an existing actor. So I create an actor (which implements ActorPublisher[TextMessage.Strict]) and then wrap it in Source.fromPublisher(ActorPublisher(myActor)).
When you want to inject a message into the stream from the actor's receive method you first check if totalDemand > 0 (i.e. the stream is willing to accept input) and if so, call onNext with the contents of the message.
I've a very strange problem with AKKA FSM.
I've a pool of fsm actor references created at the time of app initialization and the requirement is to send incoming streams of messages to all those actors references, so unfortunately some of the messages are not being sent properly.
Is there a mechanism to track the messages are delivered or not, Please let me know if anybody encountered/solved these.
Appreciate your help!
Thanks,
~Shiva
Checkout the FSM Documentation, specifically the section on Testing and Debugging Finite State Machines. In a nutshell, you need to:
Wrap your receive in a LoggingFSM
Make sure to set the config setting akka.actor.debug.fsm to true
Make sure your logging level is set to DEBUG,
If you do all of that you should start seeing debug level messages related to events/state transitions/timers for your FSM actors.
I'm reading http://danielwestheide.com/blog/2013/02/27/the-neophytes-guide-to-scala-part-14-the-actor-approach-to-concurrency.html and in it, is declared :
"Sometimes, sending an actor a message and expecting a message in
return at some later time isn’t an option – the most common place
where this is the case is in components that need to interface with
actors, but are not actors themselves. Living outside of the actor
world, they cannot receive messages.
For situations such as these, there is Akka’s ask support, which
provides some sort of bridge between actor-based and future-based
concurrency. "
When does this situation apply, ie when to use Akka ask support ?
I'm using akka to create Actor requests that in turn create web service requests so I think this is a use case as I may not get a valid web service response in appropriate time frame. Also web service requests do not live in the Akka world. Am I correct in my reasoning ? What are the real world example where I should ask instead of tell ?
I am just playing with Scalatra and Akka like the guide suggests http://www.scalatra.org/guides/async/atmosphere.html. I've modified the guid so that I'm passing an actor system into the Atmosphere client.
However, I would like to know how I can get messages from the actor system back down to the client.
I can't use the ask pattern because the actor system may send multiple messages to the client - not one. What should I do here?
Perhaps you can use The Inbox.
I am looking at the websocket-chat example. It unveils much, but I still cannot get something. I understand how messages are received, processed and sent on the web page side.
However, Play captures websocket messages by means of the receive method of an Akka actor. In the websocket-chat, there are several cases in this method, but I don't get, how does it know which websocket message should be mapped to which case. In fact, I don't understand the path that a websocket message follows upon entering Play's domain, how is it processed and how can different message types/kinds be sent from the webpage.
I have not find any info or sources related to this. Could please someone explain this or point to some kind of a good reference?
UPDATE:
The link to the original example.
The receive method from the sample doesn't have any link to the Play Websocket API. This receive method comes from the Akka library.
The Websockets events are managed through an Iteratee, which create and send a Talk message to the Actor system.
Simply put, it allows to have a highly scalable system (non-blocking), by sending messages between "workers".
So I suggest that you take a look at the Actor model in the Akka library.