![]() So, in summary: while there still is a way to get the mailbox size, you will probably never actually need it. Then you could either use down-casting (evil) or keep track of your mailboxes in an (recommended) to access the stats from within your actor and do whatever is necessary.īut wait: did I mention that it might even be easier to tag latency-critical (but not too high frequency) messages with timestamps and react on the age of a message when processing it? In case you cannot do without, it is quite easy to write your own mailbox implementation, building on the traits in the akka.dispatch package and inserting book-keeping code into enqueue() and dequeue(). Read the entire post, then reconsider your reason for obtaining the actor's mailbox size. your thread is scheduled out for 100ms and you get 100.000 new messages during that time). Making it “more correct” involves book-keeping which severely limits scalabilityĪnd even then the number might have changed completely by the time you receive it in your code (e.g. it does not need to match the real size at either the beginning or the end of processing this request querying hurts when you will feel the pain the most (it might even take several seconds in case of durable mailboxes at the “wrong moment”) It takes O(n) time to get some size answer from a concurrent queue, i.e. Here is an excerpt that outlines some problems with querying an actor's mailbox size: Roland Kuhn wrote a detailed blog post (derived from this discussion on the Akka User List) explaining the rationale behind this decision. Such a method existed in Akka 1.x but was removed in Akka 2.0.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |