I am using akka streams. So i am having one actor with this functionality.
Both messages were getting processed in order sometimes . but due to async call (I THINK) , i am getting dead letter in this.
actor.tell(message,ActorRef.noSender());
actor.tell(PoisonPill.getInstance(),ActorRef.noSender())
Can anyone help how to make sure to run this code in specific order?
It's probably that you are getting an exception which is killing the stream. Are you using a supervision strategy? If not, I would recommend following the documentation: https://doc.akka.io/docs/akka/current/stream/stream-error.html#supervision-strategies
If it is in some async call, it might be the future is throwing a TimeoutException.
Related
If node crashes and at that point of time messages are queued up in mailbox then how will those messages be reprocessed?
If they can not be reprocessed then how can we say akka programming model is fault tolerant. This is the most basic use case for which we have to use persistent queues right now.
The messages won't be processed and will be lost; Akka does not guarantee message delivery - this is explicitly stated in the beginning of its documentation. However, this does not preclude one to make the program fault-tolerant. One of the simplest ways to do so would be to implement messages with acknowledgements and make actors re-send messages which were not acknowledged.
Entire typesafe stack is built around microservices.. If you have doubt then read their presentations.. Akka streams Alla HTTP they all are in this direction... Seems your view of Microservice is different from mine... Despite that you missed the main point.. Distributed fault tolerant architecture problem was supposed to be solved by Akka.. If you are using rabbitmq then you are not going to get all benefits of akka.. Like location transparency.. Actor heiraarchy..do post your architecture diagram to Akka forums and see what response you get
As far as I understand, context.watch simply delivers actor.Terminated message to watcher. I wanted it to be the last message that actor receives. Yet, I see that it is never delivered. I guess it can be because it is terminated and does not process messages anymore. As part of the answer you may tell what is expected behaviour. You can also tell what is the way to handle the stop condition.
Seems like you've already answered your own question: watching self will not result in that actor receiving a Terminated message for itself. The real question is why you need that message. If you just need to clean up resources, override postStop and put that logic there.
postStop is guaranteed to be executed after messages have stopped being enqueued in that actor's mailbox so you can be sure nothing will come after it.
I have a design challenge in regards to a new akka application that I'm building.
The issue/challenge is:
On the client side I have made a simple actor which sends a request, and then using become() in order to wait for a proper server answer, of course also including a timeout message, in case I don't get an answer in proper time.
The interesting thing is however on the server side.
Here i have the following construction:
Actor A (Configured as a round robin router) this router is receiving all request from the client.
Actor A then forwards message to Actor A1, A2...Ax which all have been created in the context of actor A meaning it's the supervisor of them.
In the normal case the Actor Ax would be able to just reply to the sender, since the message is forwarded, however...
In case of an error I would like to besides log it on the server log, also to give the user som kind of information on the error that has happened.
In the perfect world I would prefer to be able to somehow in the supervisor strategy to just say something like getErrorActorsLastSender() and then get the ActorRef of the client which caused the issue. The reason why I prefer this, is that then I would have one place to have all the error handling, and all unforseen exceptions would always be handled at least in some generic way.
The alternative is to override the prerestart() method on each child actor, and then make the supervisor strategy to restart the actor when an exception is thrown. However this would require me to implement this method for x child actors.
Any good suggestions, if this is possible from supervisor strategy?
Thanks in advance.
Have you tried creating your own supervisor strategy, for example by extending OneForOneStrategy? There is a method called handleFailure which takes (among others) the child and the cause of the failure. Also you will get the ActorContext, which gives you the sender of the message that caused the error, I think you should be able to do what you want when you override this method.
One way to achieve your goals is to encapsulate the sender in the Exception. If you throw the Exception yourself, this should be straightforward.
I've seen different snippets demonstrating a Put message that returns unit with F#'s MailboxProcessor. In some, only the Post method is used while others use PostAndAsyncReply, with the reply channel immediately replying once the message is being processed. In doing some testing, I found a significant time lag when awaiting the reply, so it seems that unless you need a real reply, you should use Post.
Note: I started asking this in another thread but thought it useful to post as a full question. In the other thread, Tomas Petricek mentioned that the reply channel could be used a wait mechanism to ensure the caller delayed until the Put message was processed.
Does using PostAndAsyncReply help with message ordering, or is it just to force a pause until the first message is processed? In terms of performance Post appears the right solution. Is that accurate?
Update:
I just thought of a reason why PostAndAsyncReply might be necessary in the BlockingQueueAgent example: Scan is used to find Get messages when the queue is full, so you don't want to Put and then Get before the previous Put has completed.
I think I generally agree with your summary - it makes sense that PostAndAsyncReply is slower than Post, so if the caller doesn't need to get a notification from the agent when the operation (such as putting value into the queue) completes, it should definitely expose a way to do that using just Post. The fact that PostAndAsyncReply is a lot slower probably means that some agents should expose both options and let the caller decide.
Regarding the specific example of BlockingQueueAgent (or a similar one that I used to implement one-place buffer), the typical application of the agent is to solve the consumer-producer problem. In consumer-producer problem, we want to block the producer when the queue is full and block the consumer when it is empty. The .NET BlockingCollection supports only synchronous blocking, which is a bit bad (i.e. it can block the whole thread pool).
The using the BlockingQueueAgent that sends the Put messsage using PostAndAsyncReply, we can wait until the element is added to the queue asynchronously (so it blocks the producer, but without blocking threads!) An example of typical usage is the image processing pipeline that I wrote some time ago. Here is one snippet from that:
// Phase 2: Scale to a thumbnail size and add frame
let scalePipelinedImages = async {
while true do
let! info = loadedImages.AsyncGet()
scaleImage info
do! scaledImages.AsyncAdd(info) }
This loop repeatedly gets an image from the loadedImages queue, does some processing and writes the result to scaledImages. The blocking using the queue (both when reading and when writing) controls the parallelism, so that the steps of pipeline run in parallel, but it does not keep loading more and more images if the pipeline cannot handle them at the required speed.
My advice is to design your system so you can use Post as much as possible.
This technology was designed for asynchronous concurrency where the objective is to fire-and-forget messages. The idea of waiting for a response goes directly against the grain of this.
I have a remote server which handles various different commands, one of which is an event fetching method.
The event fetch returns right away if there is 1 or more events listed in the queue ready for processing. If the event queue is empty, this method does not return until a timeout of a few seconds. This way I don't run into any HTTP/socket timeouts. The moment an event becomes available, the method returns right away. This way the client only ever makes connections to the server, and the server does not have to make any connections to the client.
This event mechanism works nicely. I'm using the boost library to handle queues, event notifications, etc.
Here's the problem. While the server is holding back on returning from the event fetch method, during that time, I can't issue any other commands.
In the source code, XmlRpcDispatch.cpp, I'm seeing in the "work" method, a simple loop that uses a blocking call to "select".
Seems like while the handling of a method is busy, no other requests are processed.
Question: am I not seeing something and can XmlRpcpp (xmlrpc++) handle multiple requests asynchronously? Does anyone know of a better xmlrpc library for C++? I don't suppose the Boost library has a component that lets me issue remote commands?
I actually don't care about the XML or over-HTTP feature. I simply need to issue (asynchronous) commands over TCP in any shape or form?
I look forward to any input anyone might offer.
I had some problems with XMLRPC also, and investigated many solutions like GSoap and XMLRPC++, but in the end I gave up and wrote the whole HTTP+XMLRPC from scratch using Boost.ASIO and TinyXML++ (later I swaped TinyXML to expat). It wasn't really that much work; I did it myself in about a week, starting from scratch and ending up with many RPC calls fully implemented.
Boost.ASIO gave great results. It is, as its name says, totally async, and with excellent performance with little overhead, which to me was very important because it was running in an embedded environment (MIPS).
Later, and this might be your case, I changed XML to Google's Protocol-buffers, and was even happier. Its API, as well as its message containers, are all type safe (i.e. you send an int and a float, and it never gets converted to string and back, as is the case with XML), and once you get the hang of it, which doesn't take very long, its very productive solution.
My recomendation: if you can ditch XML, go with Boost.ASIO + ProtobufIf you need XML: Boost.ASIO + Expat
Doing this stuff from scratch is really worth it.