In akka, the dispatcher manages the threads for you. Most akka systems 
ignore the existence of the thread pool entirely except when a third party 
library requires an execution context or something and even then the best 
practice is to just reference the dispatcher. 

That aside, since the dispatcher pairs messages with threads at the time 
the message is processed and then reclaims the thread, unless you are 
blocking for a long time in the message processing (which you should never 
do) then the dispatcher can make much better use of the thread pool Instead 
of long imperative processes, the processing is broken up into many 
successive micro processes that are fed into the dispatcher. If you start 
thinking of the entire system as message processing and ditch imperative 
programming you will be most of the way there. When you get there you will 
wonder why you ever thought it was hard to begin with. 

On Monday, April 3, 2017 at 8:22:19 AM UTC-5, kant kodali wrote:
>
> Hi All,
>
> I came across this paper 
> <http://ds.cs.ut.ee/courses/previous/course-files/tmp-report-392465691.pdf> 
> and 
> I quoting the paragraph below where I have the question. The author seems 
> to suggest JVM threads are different from the threads used by Akka kernel ? 
> I am not sure what is the difference? In Java, every thread one may spawn 
> is indeed a kernel thread right? I am assuming forkJoinPool also would 
> extend the Java Thread class. If so, what really is the difference? and 
> what really is a JVM thread (AFAIK a JVM thread is indeed a kernel thread 
> right. isn't it? )
>
>
> "Concurrency in Akka is built using real threads in the lowest layer 
> called kernel. Akka’s kernel does all of the fine-grain resource management 
> and execution of actors. This causes some unpredictability to occur in the 
> execution order and performance. Different JVM configuration, state and 
> uptime may cause fluctuations in the performance of Akka-related 
> components, some actors that are written serially in the code may be run in 
> arbitrary order. The regular JVM threads are still available to use in the 
> actors, however that is not advised because it breaks the independence 
> principles of Akka components. Also the scaling properties suffer when 
> threads are used inside actors because it makes harder to scale (mainly) 
> horizontally and also when that specific actor happens to be replicated in 
> big numbers"
>
> Thanks!
>

-- 
>>>>>>>>>>      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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to