Not exactly what you are asking for, but growing mailbox size can be a symptom of starvation. You might find this utility useful for monitoring that: https://gist.github.com/patriknw/5946678
/Patrik > 29 maj 2015 kl. 15:37 skrev Richard Bradley > <[email protected]>: > > > Another approach that may as well deal with accidental issues, is to avoid > > awaiting on messages, > > I think you misunderstand me. > > I am aware of all these strategies to manage deliberate blocking, and to > avoid blocking in the first place. > > I am asking about how Akka should detect the failure case when an app does > not correctly manage blocking. In my case, this has happened accidentally due > to bugs (in particular: a library which claimed to be non-blocking was > blocking under unusual network circumstances), but it could also happen due > to poor application design. > > > Currently, Akka does not detect when this happens, and the application just > experiences pauses with no obvious developer-visible diagnosis of the cause > or aid in tracking it down. > > This is analogous to deadlocks in databases: all good databases will offer > their users hints on avoiding deadlocks, but the best databases will detect > user-caused deadlocks and emit an error log with diagnostic information that > identifies the cause and gives hints on how to fix it. > > >> On Friday, May 29, 2015 at 2:00:38 PM UTC+1, Guido Medina wrote: >> Another approach that may as well deal with accidental issues, is to avoid >> awaiting on messages, this is how I do, and again, it is working like a >> charm, say you have the following scenario: >> Actor A running on persistor-dispatcher needs to insert a record on the DB >> and send the identity of that record, or the whole inserted new record to >> Actor B which needs it. >> Actor B will at pre-start send a message to actor A requesting such record >> without waiting, just fire-and-forget, include the sender in your message. >> Actor A will answer the message with its new inserted record. >> Actor B will set context timeout for say, 1 minute and before it receives >> the record from Actor A, it stash all messages coming to it. >> Actor B if receives timeout message, deal with it with your own logic, say, >> keep working until number of timeouts exceed a number, say, 5 times or just >> kill the actor because something is wrong on Actor A. >> Actor B eventually receives the record from Actor A and at that moment it >> will unstash all messages and do the normal processing. >> Think of it as long running state machine without blocking, you are just >> reacting to either the eventual message or a timeout, does that cover all >> scenarios?, No, but I think it is a good approach to avoid blocking and >> waiting. > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
