Re: [akka-user] Basics | Threaded vs Reactive concurrency model

[Patrik Nordwall]

On Mon, Mar 16, 2015 at 11:08 AM, Saiprasad Krishnamurthy <
saiprasad.krishnamur...@gmail.com> wrote:

> I'm a complete newbie to the world of reactive programming. I'm looking
> into Akka Actors as a beginning step to play with.
>
> My understanding of the Thread Based concurrency model is (eg of a Vanilla
> Servlet based model):
>
>1. For every request from the client, a new thread is spawned.
>2. This means the execution of all the underlying code is attached to
>this thread and occur serially. Apparently even if one section of the code
>has a bottleneck (remote Webservice calls etc), the Thread will will be
>blocked and wait and remain idle.
>3. The servers (containers) has a fixed threadpool to accommodate max
>number of concurrent threads and apparently, they will quickly run of of
>threads because of bottleneck.
>
> My understanding of the Reactive concurrency model is (eg of a Akka based
> model):
>
>1. All the logic is no longer attached to a single thread and executed
>serially.
>2. The execution flow is reactive (ie on message, an actor gets
>triggered).
>
> Now my question:
>
> Assume the bottleneck of the remote webservice call exists in both the
> models. How is the actor model helps in better CPU / Core utilization?
> Won't we have the same problem of the execution threads within the actor
> getting blocked? For ex: If there are 200 actors concurrently blocked by
> this webservice call? Doesn't it mean there are 200 threads currently
> blocked?
>
Yes, blocking should be avoided, e.g. by using an asynchronous http client
for webservice calls. Sometimes it cannot be avoided, but then you can at
least manage the blocking carefully by limiting the number of actors that
are performing these tasks and by using a dedicated dispatcher (thread
pool) for such tasks.

> I understand that there will still be other actors reacting to other
> upstream events. Is this what we refer to as better utilization of the CPU?
>
Yes, other non-blocking parts can continue without being starved by the
blocking parts of the system.


> In a Threaded model, is only the small size of the Threadpool the cause of
> the problem?
>
You can only create a few thousand threads.


> Doesn't the Actor Subsystem have a threadpool to spawn off a new actor and
> react to a specific event? If yes, then don't we have the same problem?
>
Actors also run on threads, but there is not a one-to-one mapping between
an actor and a thread. Many actors can share the same thread pool.

/Patrik

> Pardon me if this question is completely stupid.
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Basics | Threaded vs Reactive concurrency model

[Saiprasad Krishnamurthy]

I'm a complete newbie to the world of reactive programming. I'm looking 
into Akka Actors as a beginning step to play with.

My understanding of the Thread Based concurrency model is (eg of a Vanilla 
Servlet based model):

   1. For every request from the client, a new thread is spawned.
   2. This means the execution of all the underlying code is attached to 
   this thread and occur serially. Apparently even if one section of the code 
   has a bottleneck (remote Webservice calls etc), the Thread will will be 
   blocked and wait and remain idle.
   3. The servers (containers) has a fixed threadpool to accommodate max 
   number of concurrent threads and apparently, they will quickly run of of 
   threads because of bottleneck.

My understanding of the Reactive concurrency model is (eg of a Akka based 
model):

   1. All the logic is no longer attached to a single thread and executed 
   serially.
   2. The execution flow is reactive (ie on message, an actor gets 
   triggered).

Now my question:

Assume the bottleneck of the remote webservice call exists in both the 
models. How is the actor model helps in better CPU / Core utilization? 
Won't we have the same problem of the execution threads within the actor 
getting blocked? For ex: If there are 200 actors concurrently blocked by 
this webservice call? Doesn't it mean there are 200 threads currently 
blocked? I understand that there will still be other actors reacting to 
other upstream events. Is this what we refer to as better utilization of 
the CPU?

In a Threaded model, is only the small size of the Threadpool the cause of 
the problem?

Doesn't the Actor Subsystem have a threadpool to spawn off a new actor and 
react to a specific event? If yes, then don't we have the same problem?

Pardon me if this question is completely stupid.

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.