CODEWITHSUNDEEP
javasocketsplayframeworksocket.ioakka
jsf
jsf

Reputation: 2981

Call thread based API from Actor Model framework like AKKA

I have a 3rd party API that utilizes Threads. I am coding using Play framework and want to make use of Akka to implement ASYC functionality and to achieve Realtime results. But I'm not sure if integrating Akka with an API that uses Threads make sense or not. Consider the following scenario:

  1. Query 3rd party API using a Socket to return a stock price using the ticker symbol
  2. 3rd party receives the message, executes commands using Threads and does whatever else it needs to do. I'm not really worried about how it does things. Just pointing out that it utilizes threads.
  3. 3rd party API starts spitting out data
  4. Process data returned. If data matches given use case, save it in the database and push it to the browser.

Could you please share where Akka can create value in this use case? Thanks a bunch

Upvotes: 0

Views: 469

Answers (2)

Latrine
Latrine

Reputation: 101

In my projects I often have to deal with blocking legacy code, database calls, old blocking network communication etc. In those cases I isolate the blocking part and execute it in a separate thread. This thread is controlled by an AKKA actor.

So what I get is full control about concurrency. I just need to limit the number of those actors. Another win is to be able to stop the blocking operation, if it deals with interrupts.

Finally, and this is the most important feature, I profit from the failure-tolerance of AKKA actors. I am able to easily stop or restart sub-components, reset external resources, etc.

So, Akka is not only about asynchronous processing, but particularly vital for failure-tolerant systems.

Upvotes: 0

Vadzim
Vadzim

Reputation: 26200

Akka is designed for async processing. So it would fit only if communication with 3rd party API is done through async non-blocking IO. This would isolate your application from any threading specifics of 3rd party side.

Update

I assume that question is on Play! version 1.x, as Play 2.0 already uses an internal Akka Actor system to handle request processing.

You should already know that

Play is intended to work with very short requests. It uses a fixed thread pool to process requests queued by the HTTP connector. To get optimum results, the thread pool should be as small as possible. We typically use the optimum value of nb of processors + 1 to set the default pool size.

So for any remote (or any potentially long-lasting) communication you'll have to do it right in async non-blocking way or perform it in separate threads to prevent play's tiny thread pool exhaustion under load. Regardless of whether your 3rd party API makes use of locks or not.

Also note that Play has some builtin support for async processing. It could be used instead of akka in this case. Just use async socket io library returning Future, convert it to Promise and await() for it. Similar to how it's done in Play's Web Service client.

Relevant question on java socket nio.

Additionally I would suggest to cache the obtained stock quotes to further improve performance. Guava Cache is a good candidate. In refresh mode it can also be used to perform periodic background requests for updated quotes even with synchronous API.

Upvotes: 1

Related Questions