tag:blogger.com,1999:blog-5670913874201002312024-02-19T11:46:10.222+05:30Akka EssentialsMunish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-567091387420100231.post-72164309361398438112013-12-05T14:58:00.002+05:302013-12-05T14:58:50.279+05:30The Road to Akka Cluster and Beyond<iframe allowfullscreen="" frameborder="0" height="421" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/28842004" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="512"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="https://www.slideshare.net/jboner/the-road-to-akka-cluster-and-beyond" target="_blank" title="The Road to Akka Cluster and Beyond">The Road to Akka Cluster and Beyond</a> </strong> from <strong><a href="http://www.slideshare.net/jboner" target="_blank">Jonas Bonér</a></strong> </div>
Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0tag:blogger.com,1999:blog-567091387420100231.post-49860123187287500872013-11-18T15:18:00.000+05:302013-11-18T15:18:09.806+05:30Design Pattern - Adding Instrumentation and other metrics collection to Akka ActorsDesign Pattern - Adding Instrumentation and other metrics collection to Akka Actors without polluting the business logic<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="486" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/27373330" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="597"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="https://fr.slideshare.net/EvanChan2/akka-inproductionpnw-scala2013" target="_blank" title="Akka in Production: Our Story">Akka in Production: Our Story</a> </strong> from <strong><a href="http://www.slideshare.net/EvanChan2" target="_blank">Evan Chan</a></strong> </div>
Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0tag:blogger.com,1999:blog-567091387420100231.post-50499166766280685682013-01-03T13:59:00.000+05:302013-01-03T15:17:19.356+05:30Akka Essentials Giveaway contest!<br />
Year 2013 has begun and what better way to start then by participating in the contest organized by Packt Publishing.<br />
<br />
<b>The Prize</b><br />
<b><br /></b>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.packtpub.com/sites/default/files/8284OS_Akka%20Essentials.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="http://www.packtpub.com/sites/default/files/8284OS_Akka%20Essentials.jpg" width="156" /></a></div>
The prizes are 2 print copies and 2 ebooks of my new book Akka Essentials that was published couple of months back.<br />
<br />
Akka Essentials will show you the current challenges with Java Scalability and concurrency model and how Akka’s Actor Model can help you design and build applications that are inherently scalable and fault-tolerant. Whether you are building new applications or want to refactor an existing application, you will learn the right techniques to build and scale up in no time.<br />
<br />
This book is aimed at developers, architects who are building large distributed concurrent and scalable applications using Java/Scala.<br />
<br />
<br />
<br />
What you will learn from Akka Essentials:<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Scale up and out your applications using dispatchers and remoting<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Build fault tolerance within your application<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Handle transactions within your application<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Unit test your Akka applications<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Integrate your Akka applications with existing enterprise systems using Zeromq<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Monitor the health of your Akka application<br />
<br />
<b>How to Win Akka Essentials</b><br />
<br />
You can enter by writing a comment to this post explaining why you would like to have the book. The contest has already started and will end on January 31st 2013 at 11:59 PM GMT. Winners will be randomly chosen and notified by email, after termination of the contest. <u>Please do not forget to leave your email id in the comment.</u><br />
<br />
The contest is open to everybody in the world, however print copies are only available to residents of the US<br />
and Europe.<br />
<br />
Comments are moderated by me, so your comment will not appear immediately.<br />
<br />
I wish all the contest participants good luck.<br />
<div>
<br /></div>
Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com16tag:blogger.com,1999:blog-567091387420100231.post-14525146583198968262013-01-02T01:00:00.000+05:302013-01-02T01:00:00.420+05:30Software Transactional Memory (STM)The Actor Model is based on the premise of small independent processes working in isolation and where the state can be updated only via message passing. The actors hold the state within themselves, but the asynchronous message passing means there is no guarantee that a stable view of the state can be provided to the calling components. For transactional systems like banking where account deposit and withdrawal need to be atomic, this is a bad fit with an Actor Model.So, if your Akka applications need to be implementing a shared state model and providing a consensual, stable view of the state across the calling components, Software Transactional Memory (STM) provides the answer.
<br />
<br />
STM provides a concurrency-control mechanism for managing access to shared memory. STM makes use of two concepts – <b>optimism </b>and <b>transactions </b>to manage the shared concurrency control. <br />
<ul>
<li>Optimism means that we run multiple atomic blocks in parallel, assuming there will be no errors. When we are done, we check for any problems. If no problems are found, we update the state variables in the atomic block. If we find problems then we roll back and retry. Optimistic concurrency typically provides better scalability options than any other alternate approaches. </li>
<li>Secondly, STM is modeled on similar lines of database transaction handling. In the case of STM, the Java heap is the transactional data set with begin/commit and rollback constructs. As the objects hold the state in memory, the transaction only implements the following characteristics – atomicity, consistency, and isolation.</li>
</ul>
<a name='more'></a>To manage multiple transactions running on separate threads as a single atomic block, the concept of <i>CommitBarrier </i>is used. <i>CommitBarrier </i>is a synchronization aid that is used as a single, common barrier point by all the transactions across multiple threads. Once the barrier is reached, all the transactions commit automatically. It is based on the Java's <i>CountDownLatch</i>.<br />
<br />
Akka transactors are based on <i>CommitBarrier</i>, where the atomic blocks of each actor (member) participating are treated as one, big single unit. Each actor will block until everyone participating in the transaction has completed. This means that all the actions executed as part of the atomic blocks by members of the <i>CommitBarrier </i>will appear to occur as a single atomic action even though the members may be spread across multiple threads. If any of the atomic blocks throw an exception or a conflict happens, all the <i>CommitBarrier </i>members will roll back.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilPVGhFeakBkgTVTLcgHQ6_h1RpmiLz0qsLiT48VxFMLlGLFUYc78yTIgu7LfxwJALnqwy0PWKmp2DWf7Emnjq_g7h_koiPPrcN4YChjsRLht49O8vA6c3TzN-bhKco1pMHZ51dr9WF1mq/s1600/Coordinated+Transactions.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="173" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilPVGhFeakBkgTVTLcgHQ6_h1RpmiLz0qsLiT48VxFMLlGLFUYc78yTIgu7LfxwJALnqwy0PWKmp2DWf7Emnjq_g7h_koiPPrcN4YChjsRLht49O8vA6c3TzN-bhKco1pMHZ51dr9WF1mq/s400/Coordinated+Transactions.png" width="400" /></a></div>
Akka provides a construct for coordinating transactions across actors called <i>coordinated.coordinated</i>, which is used to define the transaction boundary in terms of where the transaction starts, and the <i>coordinated.coordinate()</i> method is used to add all the members that will participate in the same transaction context.<br />
<br />
<br />
<b>Money transfer between two accounts</b><br />
<b><br /></b>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH2dtb2Yuw3eSp3Jj8YYXcKDYls_CuaerWU5sz2kaxAR5HVeEwj_48AhbwfG8mmauMqXaEisJiFbi0ZeQTGKOlDvKoF7eLT-y6JlV_z4B1pVco2lRjVkj9RCVrXova_LGTQ1IwbEyIVe-T/s1600/money-transfer.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH2dtb2Yuw3eSp3Jj8YYXcKDYls_CuaerWU5sz2kaxAR5HVeEwj_48AhbwfG8mmauMqXaEisJiFbi0ZeQTGKOlDvKoF7eLT-y6JlV_z4B1pVco2lRjVkj9RCVrXova_LGTQ1IwbEyIVe-T/s320/money-transfer.png" width="320" /></a></div>
Let's take an example and see how the actors can participate in the transactions. We will use the classic example of transfer of funds between two bank accounts . We have an AccountActor that holds the account balance and account number information. It has two operations – credit (add money to the account) and debit (take money away from the account). In addition, we have the TransferActor object that will hold the two AccountActor objects and then invoke the debit and credit operations on the account objects.<br />
<br />
<br />
<br />
To make sure that the money transfer in the account happens in a synchronized way, we need to implement the following:<br />
<ul>
<li>In the account object, the state variable that needs to participate in the transaction should be of transaction reference type.</li>
<li>The credit and debit operations in the account object need to be atomic. </li>
<li>In the transfer object, the transaction boundary needs to be defined and the account objects need to participate in the same transaction context.</li>
<li>In addition, we define the supervisor policy in TransferActor and BankActor to handle the transaction exceptions:</li>
</ul>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx_cTMhWagos3GM9yTJJWatiGXOtbnwyE3PiYTp-2jvH1zXz9FyeeBsZ06pkWYyTVTcD2U1gQ6PLxF4pFR37jlKVMnCze3-t7gWJ2OtHeQ8F25RdEVdJ6czEZ9NDHOiStay-FynfUeEUyo/s1600/money-transfer1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx_cTMhWagos3GM9yTJJWatiGXOtbnwyE3PiYTp-2jvH1zXz9FyeeBsZ06pkWYyTVTcD2U1gQ6PLxF4pFR37jlKVMnCze3-t7gWJ2OtHeQ8F25RdEVdJ6czEZ9NDHOiStay-FynfUeEUyo/s400/money-transfer1.png" width="400" /></a></div>
<br />
Parts of the post are excerpts from the book - <a href="http://packtpub.com/akka-java-applications-essentials/book">Akka Essentials</a>. For more details on the example, please refer to the book.<br />
<br />Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0tag:blogger.com,1999:blog-567091387420100231.post-6904858013986240102012-12-28T13:12:00.000+05:302012-12-28T13:12:15.155+05:30Adding Turbchargers to JEE AppsOne of the key roles, I play is evangelizing Akka within my local community. As part of the discussions, the question/doubt usually in people's mind is how can Akka provide better scalability and concurrency against a well written Java/JEE application. Since the underlying hardware/JVM remains the same, how can the actor model ooze out more power than the traditional JEE applications. In order to showcase the skeptics we decided to do small test where we take an existing JEE Web application, remodel the business logic to make use of the actor model and run tests against the same.<br />
<br />
<b><span style="font-size: large;">DayTrader Application</span></b><br />
<br />
DayTrader is a benchmark application built around the paradigm of an online stock trading system. The application allows users to login, view their portfolio, lookup stock quotes, and buy or sell stock shares. DayTrader not only serves as an excellent application for functional testing, but it also provides a standard set of workloads for characterizing and measuring application server and component level performance.<br />
<br />
DayTrader is built on a core set of Java EE technologies that includes Java Servlets and JavaServer Pages (JSPs) for the presentation layer and Java database connectivity (JDBC), Java Message Service (JMS), Enterprise JavaBeans (EJBs) and Message-Driven Beans (MDBs) for the back-end business logic and persistence layer.<br />
<br />
More information about DayTrader is available <a href="https://cwiki.apache.org/GMOxDOC20/daytrader.html">here</a>.<br />
<div>
<br />
<a name='more'></a></div>
DayTrader seemed the right fit of an application to test our theory. We decided on the JSP->JDBC model to keep things simple and comparable. We took 2 use cases and remodelled the business logic to make use of the TypedActors.<br />
<br />
<b>Scenario 1 - Quote/Trade screen – Get quotes </b><br />
In the Quotes/Traders screen of DayTrader application there is a facility for selecting the details of a list of quotes by clicking the quotes button. The price quotes for the stock shares will be retrieved and displayed to the user.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7WuvPgbLUEIvSguIzTMjy0NchGw7WsBF82ogANS9ObPtwNFypgCDgrRg7Fd4OPHxDI6SnopRrKCvhMu0IGA73OOq-xHdAjTtPYvhXAhxmuQT3IeoR-W8QbYVE6w30IvdALPHwySFSeiak/s1600/case+1.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7WuvPgbLUEIvSguIzTMjy0NchGw7WsBF82ogANS9ObPtwNFypgCDgrRg7Fd4OPHxDI6SnopRrKCvhMu0IGA73OOq-xHdAjTtPYvhXAhxmuQT3IeoR-W8QbYVE6w30IvdALPHwySFSeiak/s400/case+1.png" width="376" /></a></div>
<br />
In the standard flow, the get quote request is handled by a dedicated TradeAction which internally invokes the getQuote() interface of the TradeDirectJEEE object. For each request a TradeAction object is created.<br />
<br />
<br />
<br />
In the updated flow, a set of worker actors was created which listens for requests from various modules to get the quote details. The TradeActionManager will create the Typed actor pool at the start and it will also have operations to route the incoming requests to the Typed actors which hold the TradeAction objects for invoking the getQuote function. Since Typed actors are used the same TradeActionManager can cater to other TradeAction calls with minimal changes in the existing application.<br />
<br />
<br />
Both the orignal and the modified DayTrader application was executed with 20, 50, 75 and 100 Typed actors with as many Trade Action objects.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2a5FFl_qFFyekJaRngbO2nPdRKjgYYFQXnemRr14lGI0QQ-jbC1U9qT-rY4JgVgKFTOrn0isPXsxfcls_j0_J7XRHXFzC7dnFhuExcKplqc8HxchgnGvjFTZ6zImYD5dMF8iK4mv7r4hJ/s1600/case2.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2a5FFl_qFFyekJaRngbO2nPdRKjgYYFQXnemRr14lGI0QQ-jbC1U9qT-rY4JgVgKFTOrn0isPXsxfcls_j0_J7XRHXFzC7dnFhuExcKplqc8HxchgnGvjFTZ6zImYD5dMF8iK4mv7r4hJ/s400/case2.png" width="400" /></a></div>
<br />
<i>The graph shows the relative throughput for each tested scenario with dark red bars indicating the throughput values of the original application and the other bars indicating the throughput for application with Akka for different actor pool sizes. </i><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<ul>
<li>Akka Typed Actors has given per second throughput better than the original DayTrader application (for larger actor pool sizes) with lesser memory usage (especially for 700 and 300 users * 2 requests each). </li>
<li>The original application required an additional 168 MB for serving 1400 requests (700 users with 2 requests each) whereas for the modified application with a Typed Actor pool size of 50 actors the additional memory used for serving the same kind of request volume was observed to be 104 MB which is an <b>improvement of 38%</b>. For 75 and 100 typed actors the additional memory usage was observed to between 126MB-136MB.</li>
</ul>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBTHtOWWBfYMg1zazILSY9WR22JQ0oxBMnfLfALc5zf_gToHP7ctFRl4JQZVSdpclmTd00igOF4DOLzDFf2TFnGPteEblYaq15OpAiYuElODa-sO71F4EvWattAIHD6Bc3jWzxOK1MyCil/s1600/case3.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="308" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBTHtOWWBfYMg1zazILSY9WR22JQ0oxBMnfLfALc5zf_gToHP7ctFRl4JQZVSdpclmTd00igOF4DOLzDFf2TFnGPteEblYaq15OpAiYuElODa-sO71F4EvWattAIHD6Bc3jWzxOK1MyCil/s320/case3.png" width="320" /></a></div>
<i><br /></i>
<i><br /></i>
<i><br /></i>
<i>The graph shows the relative throughput for each tested scenario with dark red bar indicating the throughput values of the original application and the other bars indicating the throughput for application with Akka for different actor pool sizes. </i><br />
<i><br /></i>
<i><br /></i>
Using Jmeter simulation of the get quotes call was done for 300 users in parallel for 100 and 200 actors for different system and Akka settings for about 45minutes for each case under the same high load conditions.<br />
<br />
<br />
<br />
<br />
<ul>
<li>It was observed that increasing the number of Typed Actors from 100 to 200 has improved the throughput relatively by about 15% and 18% relative to the original application under the same condition.</li>
<li>It is also observed that an increase in the heap size to 1024 MB and changing the garbage collection method to concurrent mark sweep helped improve the throughput for high load condition. </li>
</ul>
<b>Scenario 2 - 4 screens - Login, home page, get Quote, buy </b><br />
<div>
A more complex use case consisting of 4 user screens was tried in which the user will use four steps to complete the use case scenario. The four steps are<br />
<br />
<ol>
<li>User logs in via the login page</li>
<li>User presented with the home page after submitting the login credentials.</li>
<li>Get the quotes for stock shares the symbols of which are entered by the user in the home page screen.</li>
<li>Buy the stock shares after submitting the quantity to be bought under each symbol.</li>
</ol>
<br />
All the requests use the TradeAction object to service the request. The TradeAction object implements the TradeService interface. Therefore the same TypedActor model implemented for the Quote/Trade screen – Get quotes scenario identified in the previous case was applied in this case also without little or no changes in the TradeAction module.<br />
<br />
Using Jmeter simulation of the use case consisting of four screens was done for 300 users with different Typed Actor pool sizes. The number of users was set to ramp up to the maximum of 300 users in 60 seconds and the test was run for 15 minutes.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX0O0Zx9d2vRHlJNIeCyHjHyn-xx63UaPO8dW3rRraVqvCjpf2RQBQJIVcrfaN1iByfpfZO_4jOvUbeeuUrrCbZbb4UlXcpirrQM2FPk1avuZQ64l6ah1TGjwNmsA14CTcfSAww4iq0Osh/s1600/case4.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="269" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX0O0Zx9d2vRHlJNIeCyHjHyn-xx63UaPO8dW3rRraVqvCjpf2RQBQJIVcrfaN1iByfpfZO_4jOvUbeeuUrrCbZbb4UlXcpirrQM2FPk1avuZQ64l6ah1TGjwNmsA14CTcfSAww4iq0Osh/s320/case4.png" width="320" /></a></div>
<br />
<br />
It is observed that increasing the number of actors from 0 to 300 has improved the throughput by about 8%. <br />
<br />
Any increase beyond 300 Typed actors has shown lesser improvement.<br />
<br />
<br />
<br />
<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLnNJFeuuF5uH5Kut9IOVJJq3-N2G3uO1Jmf-D6yOiEjCJ1BiTm7M0F5L2-7nMw8LpJXMu9DtPV6swVhpeeM_zwVMM45VHaUNiSRbupe0eeu04OtBcc-CoOy0AYc1L-8N5CQAlOHmnwOik/s1600/case5.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><img border="0" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLnNJFeuuF5uH5Kut9IOVJJq3-N2G3uO1Jmf-D6yOiEjCJ1BiTm7M0F5L2-7nMw8LpJXMu9DtPV6swVhpeeM_zwVMM45VHaUNiSRbupe0eeu04OtBcc-CoOy0AYc1L-8N5CQAlOHmnwOik/s640/case5.png" width="640" /></a><br />
<br />
<br />
The peak memory usage for application using typed actors has seen an improvement of
about 30-40% for the same throughput (100 typed actors) relative the original
application’s memory usage.<br />
<o:p></o:p></div>
<br />
<span style="color: #333333;"><b>Conclusion</b></span>
<span style="color: #333333;">Even with a simple change, the application running on a standard laptop was able to provide better throughput (<b>+8%</b>) and the overall memory usage went down <b>38% </b>which points to the efficiency of the actor model and Akka's handling of the memory and threads.</span>
<br />
<span style="color: #333333;"><br /></span>
<span style="color: #333333;"></span><br />
<span style="color: #333333;"><b>Details of Testing Environment</b></span><br />
<span style="color: #333333;">Processor - Intel Core i5-2410M CPU @ 2.30 GHz</span><br />
<span style="color: #333333;">RAM - 4 GB</span><br />
<span style="color: #333333;">OS - Windows 7 Enterprise</span><br />
<span style="color: #333333;">Application Server - Apache Geronimo v2.2.1</span><br />
<span style="color: #333333;">Compiler and Build tool - Apache Maven v2.2.1</span><br />
<span style="color: #333333;">Java version - 1.7.0_03</span><br />
<span style="color: #333333;">Akka Version - Akka 2.0.2</span><br />
<span style="color: #333333;">Database – Apache Derby</span><br />
<br />
<span style="color: #333333;"><br /></span>
<span style="color: #333333;">Additional optimizations we could have done</span><br />
<ul>
<li><span style="color: #333333;">Akka untyped actors pools that are grouped based on the request pattern. Say one small pool catering only for requests that are less frequently used and a large pool (or multiple pools) catering to requests like Get Quote or Get Account that are more frequently used. The ratio of the pool sizes may be changed based on the request pattern to obtain better throughput.</span></li>
<li><span style="color: #333333;">Use actor’s PreStart and PostStart functions to add initialization tasks for the database like getting a connection and closing a connection or any other initialization tasks.</span></li>
<li><span style="color: #333333;">Akka untyped actors for concurrent processing of holdings, multiple quotes for the same account and session.</span></li>
<li><span style="color: #333333;">Use the Akka actor hierarchy so that there are multiple levels of actors with the higher level supervisor actor dividing a task into smaller subtasks and delegating to the child actors in the next level.</span></li>
<li><span style="color: #333333;">Optimizing the Akka dispatcher thread pool size for the actor system.</span></li>
</ul>
<span style="color: #333333;"><br /></span>
<span style="color: #333333;">I want to say thank you to my colleague Chintu Vijay who conducted and run the tests.</span><br />
<br />Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com3tag:blogger.com,1999:blog-567091387420100231.post-36641694578176776582012-05-22T12:20:00.000+05:302012-06-02T14:26:09.350+05:30Playing PingPong with STM - Refs and Agents<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG_ZXLedQgJbsa5z6d7daM3VLk7rrPoODKazzgd-vvh8YE4LF0rMjUNs0FTnhz-ZIdeoxavHsGdsXj2rJBte4w8oZrqYnvBsgoGCE4_GfmVsPGo7U69varbWX2cQT7VoF_5UMaZt4c694m/s1600/PingPong.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG_ZXLedQgJbsa5z6d7daM3VLk7rrPoODKazzgd-vvh8YE4LF0rMjUNs0FTnhz-ZIdeoxavHsGdsXj2rJBte4w8oZrqYnvBsgoGCE4_GfmVsPGo7U69varbWX2cQT7VoF_5UMaZt4c694m/s320/PingPong.png" width="312" /></a>
PingPong is a classic example where 2 players (or threads) access a shared resource - PingPong Table and pass the Ball (state variable) between each other. With any shared resource, unless we synchronize the access, the threads can run into potential deadlock situation.<br />
<br />
The PingPong algorithm is very simple<br />
<br />
<blockquote class="tr_bq">
if my turn {<br />
update whose turn is next<br />
ping/pong - log the hit<br />
notify other threads<br />
} else {<br />
wait for notification<br />
}</blockquote>
<br />
<br /><br />
Let's take an example and see how this works! Here is our Player class, which implements Runnable and takes in the access to the shared resource and a message<br /><br /><a name='more'></a><br /><br />
<br />
<script src="https://gist.github.com/2766989.js?file=Player.java">
</script><br />
Second, we see the PingPong table class, which has a synchronized method hit() where a check is made, if my turn or not. If my turn, log the ping and update the shared variable for opponent name.
<br />
<br />
<script src="https://gist.github.com/2767029.js?file=PingPong.java">
</script><br />
Next, we start the game and get the players started!
<br />
<script src="https://gist.github.com/2767054.js?file=Game.java">
</script> That's all, we have our PingPong game running.
In this case, we saw how the synchronized method hit() allows only one thread to access the shared resource - whoseTurn.<br />
<br />
Akka STM provides two constructs Refs and Agents. Refs (Transactional References) provide coordinated synchronous access to multiple identities. Agents provide uncoordinated asynchronous access to single identity.
<br />
<h2>
Refs</h2>
In our case, since share state variable is a single identity, usage of Refs is overkill but still we will go ahead and see their usage.<br />
<br />
<br />
<script src="https://gist.github.com/2767084.js?file=PingPong.java">
</script>
<br />
The key here are the following
<br />
<ul>
<li>The <i>synchronized</i> keyword is missing</li>
<li>Definition of the state variable as Ref<br />
//updates to Ref.View are synchronous<br />
<i>Ref.View<string> whoseTurn;</i></li>
<li>Calls to update Ref are coordinated and synchronous <br />
<i>whoseTurn.set(opponent)</i>;</li>
</ul>
So, when we use the Ref to hold the state, access to the Refs is automatically synchronized in a transaction.
<br />
<h2>
Agents</h2>
Since agents provide uncoordinated asynchronous access, using agents for state manipulation would mean that we need to wait till all the updates have been applied to the agent. Agents provide a non blocking access for gets.
<br />
<script src="https://gist.github.com/2767135.js?file=PingPong.java">
</script><br />
The key here are the following
<br />
<ul>
<li>The <i>synchronized</i> keyword is missing</li>
<li>Definition of the state variable as Agent<br />
//updates to Ref.View are synchronous<br />
<i>Agent<string> whoseTurn;</i></li>
<li>Wait for updates to the agent, as updates to agent are async<br /><i>String result = whoseTurn.await(new Timeout(5, SECONDS));</i></li>
<li>Calls to update Ref are coordinated and synchronous <br />
<i>whoseTurn.send(opponent)</i>;</li>
</ul>
All the code referred in these example is available at - <a href="https://github.com/write2munish/Akka-Essentials/tree/master/AkkaSTMExample/src/main/java/org/akka/essentials/stm/pingpong">https://github.com/write2munish/Akka-Essentials/tree/master/AkkaSTMExample/src/main/java/org/akka/essentials/stm/pingpong</a>
with<br />
Example 1 - for normal thread based synchronization<br />
Example 2 - Usage of Refs for synchronization<br />
Example 3 - Usage of Agents for synchronizationMunish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0tag:blogger.com,1999:blog-567091387420100231.post-3384893567904761262012-05-08T18:52:00.000+05:302012-06-02T14:23:52.177+05:30Using TestKit with JavaUnit testing toolkit is provided via TestKit in Akka. The scala side of unit testing is well covered. For java, TestKit provides limited constructs. The various examples implemented by Ray Roestenburg have been ported to Java world, with couple of more scenario's added. This can be good starting point for Java programmers to start unit testing their actors.<br />
<br />
Let’s check out some testing code which tests out the following different set of actors
<br />
<ul>
<li><b>
Echo Actor</b> – responds back with whatever is passed to the actor</li>
<li><b>
Forwarding Actor</b> – forwards the message to another actor</li>
<li><b>
Sequencing Actor</b> – replies back in a series of messages but assuming we are interested in one</li>
<li><b>
Filtering Actor</b> – replies back for certain messages and ignores the others</li>
<li><b>
Boom Actor</b> – throws an exception when a message is send</li>
<li><b>
Supervisor Actor</b> – manages an another worker actor, and based on the exception thrown by the worker actor, applies the appropriate supervisor strategy</li>
</ul>
<br />
<a name='more'></a><br />
<script src="https://gist.github.com/2634916.js?file=UnitTestExample.java">
</script>
The code base for the program is available at the following location - https://github.com/write2munish/Akka-Essentials under the AkkaUnitTestMunish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com7tag:blogger.com,1999:blog-567091387420100231.post-65386149625082874092012-03-26T13:24:00.000+05:302012-06-02T14:23:02.195+05:30Implementing Master Slave / Grid Computing Pattern in AkkaMaster Slave pattern is a prime example of fault tolerance and parallel computation. The idea behind the pattern is to partition the work into identical sub tasks which are then delegated to Slaves. These slave node or instances will process the work task and send back the result to the master. The master will then compile the results received from all the slave nodes. Key here is that the Slave nodes are only aware on how to process the task and not aware of what happens to the output.<br />
<br />
The Master Slave pattern is analogous to the Grid Computing pattern where a control node distributes the work to other nodes. Idea is to make use of the nodes on the network for their computing power. SETI@Home was one of the earliest pioneers in using this model.<br />
<br />
I have build a similar example with difference being that worker nodes get started on Remote Nodes, Worker Nodes register with Master(WorkServer) and then subsequently start processing work packets. If there is no worker slave registered with Master(WorkServer), the master waits the workers to register. The workers can register at any time and will start getting work packets from there on.<br />
<br />
<a name='more'></a><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7RKNMl_vv60eSkprsjVls1q9km8yOwBu2pg0cOOurpRttJ9vlN58f11CsOU_YDEzYd9LrEmRTtHxDdbhPIsxd5wGngsbAq1iglQ8ZcOB0cbWuW__t1RZeE1IWUWslqf4oXtWSeDtcHGT8/s1600/GridExample.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="440" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7RKNMl_vv60eSkprsjVls1q9km8yOwBu2pg0cOOurpRttJ9vlN58f11CsOU_YDEzYd9LrEmRTtHxDdbhPIsxd5wGngsbAq1iglQ8ZcOB0cbWuW__t1RZeE1IWUWslqf4oXtWSeDtcHGT8/s640/GridExample.png" width="640" /></a></div>
<br />
The example demonstrates how an WorkerActor system sends a request for registration. The RegisterRemoteWorker recieves the request and forwards the same to JobController where the RoundRobinRouter is updated for the new worker information. The WorkScheduler sends a periodic request to JobController, who then sends packets to all the registered worker actors.<br />
<br />
The example does not implement fault tolerance with respect to on how to handle failures when the remote actors die or how to re-process packets that have not been processed. Similarly, there may be cases where the remote worker actors might want to shutdown after processing certain amount of packets, they can then indicate to the master to stop giving them work. I will add fault tolerance soon!<br />
<br />
<b>Updated</b>: Code base updated to handle worker shutdowns. If the remote actors die or shut down, the JobController detects the fail-overs using remote actor listeners and updates the router.<br />
<br />
The code base for the program is available at the following location - <a href="https://github.com/write2munish/Akka-Essentials" style="background-color: #fefdfa; color: #7d181e; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;">https://github.com/write2munish/Akka-Essentials</a> under the GridPatternExample<br />
<br />Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com2tag:blogger.com,1999:blog-567091387420100231.post-80160919334295112182012-03-15T14:05:00.001+05:302012-06-02T14:22:38.896+05:30Processing 10 million messages with AkkaAkka Actors promise concurrency. What better way to simulate that and see if how much time it takes to process 10 million messages using commodity hardware and software without any low level tunings. I wrote the entire 10 million messages processing in Java and the overall results astonished me.<br />
<br />
When I ran the program on my iMac machine with an intel i5 - 4 core, 4 Gb RAM machine and JVM heap at 1024Mb, the program processed 10 million machines in 23 secs. I ran the program multiple times and the average time was in the range of 25 secs. So the through put I received was almost in the range of 400K messages per second which is phenomenal.<br />
<br />
<a name='more'></a><br />
The below picture explains the flow used to simulate the load generation scenario.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkrzAhhkD6vLhr43cyPKnaBoFnuRCrU2CxndQEd5LCzvGR3u_zDPZfWj_erImIf6ES49nQNPkma5ytBS2EK7cS0XTOaXjz7VIFv_gdPn5MuzK0IROTTsw1bFXdlP6au0SwxIEiSwLTaq90/s1600/Load+Generator.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="260" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkrzAhhkD6vLhr43cyPKnaBoFnuRCrU2CxndQEd5LCzvGR3u_zDPZfWj_erImIf6ES49nQNPkma5ytBS2EK7cS0XTOaXjz7VIFv_gdPn5MuzK0IROTTsw1bFXdlP6au0SwxIEiSwLTaq90/s640/Load+Generator.png" width="640" /></a></div>
<br />
<b>Caveat: </b>Each message sends a response after 1 second which is not the right simulation for a real world scenario. The message processing will consume some resources on the heap and gc activity which are not accounted for, in this scenario.<br />
<br />
The program uses overall direction from the post <a href="http://www.crosson.org/2012/03/akka-actors-10-millions-messages.html">Akka actors : 10 millions messages processed (1s / message) in 75 seconds !</a> although without any messages throttling.<br />
<br />
<span style="background-color: #fefdfa; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">The code base for the program is available at the following location - </span><a href="https://github.com/write2munish/Akka-Essentials" style="background-color: #fefdfa; color: #7d181e; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px; text-decoration: none;">https://github.com/write2munish/Akka-Essentials</a>
<br />
<br />
The ApplicationManagerSystem creates the actors and pumps in the traffic to the WorkerActor
<br />
<br />
<script src="https://gist.github.com/2048560.js?file=ApplicationManagerSystem.java">
</script>
Once the messages are received by the WorkerActor, the responses are scheduled to be send after 1000 milli secs
<br />
<br />
<script src="https://gist.github.com/2048560.js?file=WorkerActor.java">
</script>
<br />
<br />
The response messages from the WorkerActor are send across to the JobControllerActor, that collects all the responses.
<br />
<br />
<script src="https://gist.github.com/2048560.js?file=JobControllerActor.java">
</script>Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0tag:blogger.com,1999:blog-567091387420100231.post-58331355863425546362012-03-14T18:57:00.000+05:302012-06-02T14:22:15.690+05:30Word Count MapReduce with AkkaIn my ongoing workings with Akka, i recently wrote an Word count map reduce example. This example implements the Map Reduce model, which is very good fit for a scale out design approach.<br />
<br />
<b>Flow </b><br />
<br />
<ol>
<li>The client system (FileReadActor) reads a text file and sends each line of text as a message to the ClientActor. </li>
<li>The ClientActor has the reference to the RemoteActor (
WCMapReduceActor ) and the message is passed on to the remote actor</li>
<li>The server (WCMapReduceActor) gets the message. The Actor uses the PriorityMailBox to decide the priority of the message and filters the queue accordingly. In this case, the PriorityMailBox is used to segregate the message between the mapreduce requests and getting the list of results (DISPLAY_LIST)message from the aggregate actor. </li>
<li>The
WCMapReduceActor sends across the messages to the MapActor (uses RoundRobinRouter dispatcher) for mapping the words</li>
<li> After mapping the words, the message is send across to the ReduceActor(uses RoundRobinRouter dispatcher) for reducing the words </li>
<li>The reduced result(s) are send to the Aggregate Actor that does an in-memory aggregation of the result </li>
</ol>
<br />
<a name='more'></a><br />
The following picture details how the program has been structured<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9HOv715mzT57A5fiT2X1b_BMwiy8DVLaQ2Qq_avdsy7JgGpQClRe-eyn7UyUURjYCw23XJYrSR8sOLUHF-qqp01R1ETNHdck75jjcFRfeN-hQxNaJmbhL1LrdCNZJmKt3yyE7VtBCSgN8/s1600/WCMapReduce.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="433" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9HOv715mzT57A5fiT2X1b_BMwiy8DVLaQ2Qq_avdsy7JgGpQClRe-eyn7UyUURjYCw23XJYrSR8sOLUHF-qqp01R1ETNHdck75jjcFRfeN-hQxNaJmbhL1LrdCNZJmKt3yyE7VtBCSgN8/s640/WCMapReduce.png" width="640" /></a></div>
<br />
The code base for the program is available at the following location - <a href="https://github.com/write2munish/Akka-Essentials">https://github.com/write2munish/Akka-Essentials</a><br />
<br />
For more information on MapReduce, read the post <a href="http://www.techspot.co.in/2011/07/mapreduce-for-dummies.html">MapReduce for dummies</a>Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com2tag:blogger.com,1999:blog-567091387420100231.post-84322133463131975252012-03-02T15:41:00.000+05:302012-05-04T09:22:49.941+05:30What is Akka?Before I delve into what is an Akka, let us take a step back to understand how the concept of concurrent programming has evolved in the application development world. The applications have evolved from being large monolithic procedures to a more object oriented model. With the advent of Java EE and Spring framework, the application design evolved into more of a process or task based design model. The EJBs or Pojo’s are designed to perform one single task. This model promoted the objects to be stateless (although state full session beans were allowed) in order to be able to handle the increasing load (aka scalable application). The overall business function request will get broken down to multiple beans (Ejbs or Pojos) which will process the information; the result from the beans will be aggregated and presented back to the requester. This model allowed the application to scale up.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuRFhZ7PGYDDdZvrF2IDuKCAdC1loknvm7eKBQq64zw8wmRBZLlbAV9tEzK4hq-6gqyLXLWiFEHW-yfP6Td6RMmd5VJdP2A7F7LFf3QfTkVYbx_GSwQEYyaGQOBBP_AMUoWVhA6Vz0XEUN/s1600/Programming+Model+Evolution.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="336" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuRFhZ7PGYDDdZvrF2IDuKCAdC1loknvm7eKBQq64zw8wmRBZLlbAV9tEzK4hq-6gqyLXLWiFEHW-yfP6Td6RMmd5VJdP2A7F7LFf3QfTkVYbx_GSwQEYyaGQOBBP_AMUoWVhA6Vz0XEUN/s400/Programming+Model+Evolution.png" width="400" /></a></div>
Now, when the same model needed to be applied to the Java application that does not make use of EJBs or application server containers, the available choice of technology or technique was to use multi-threaded programming. Working with threads require a much higher level of programming skills, since dealing with state, locks , mutex etc is not easy skill. With Java EE 1.4 onwards, newer API in terms of <a href="http://docs.oracle.com/javaee/1.4/api/javax/resource/spi/work/ExecutionContext.html">ExecutionContext </a>and Java 1.5 onwards concurrent data structure libraries (<a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-summary.html">java.util.concurrent</a>) were introduced. This allowed programmers to write programs that could be broken down into smaller tasks and run parallel on the underlying threads.<br />
<br />
For an average java programmer, writing multi-threaded programs that could break a big process into smaller tasks and run those tasks in parallel to take advantage of the multiple cores is not so easy. Akka team abstracted this whole concept using an Actor model to another plane where writing programs that process tasks in parallel became slam dunk. The Akka abstraction model allowed programmers to write programs to take advantage of multiple cores and process hundreds of tasks in parallel. The Akka team borrowed concepts and techniques from ERlang to build “Let it Crash” fault tolerance model to allow applications to fail fast and recover from the failure as soon as possible.<br />
<br />
<blockquote class="tr_bq">
<i>Akka provides a scalable real time transaction processing library that allows your application to scale up, scale out and has fault tolerance.
</i></blockquote>Munish Guptahttp://www.blogger.com/profile/07779305857165175881noreply@blogger.com0