Scala and Akka actors with Prime Sieves

I had the chance to develop the problem of prime sieves in Scala. I took two approaches; (1) Scala Actors and (2) Akka Actors in Scala. The code for both is quite similar.

Scala version

import scala.actors.Actor

case class sieve(n: Int)
case class finish(n: Int)

class Sieve(val p: Int) extends Actor {

  var next: Sieve = null

  def _sieve(n: Int) = {
    if (isPrime(n)) {
      if (next != null) {
        next ! sieve(n)
      } else {
        next = new Sieve(n)
        next.start
        //println(n + " is prime")
      }
    }
  }

  private def isPrime(n: Int): Boolean = {
    val d = n / p
    val r = n - d * p
    if (r != 0) true else false
  }

  def act = {
   loop {
   react {
case sieve(n: Int) => _sieve(n)
case finish(n: Int) => {
if (next != null) {
next ! finish(n)
} else {
val time = System.currentTimeMillis - Main.start
println(n + "," + time)
// System.exit(0)
}
}
   }
   }
  }

}

object Generator {

  def generate(n: Int): Unit = {
    val p2 = new Sieve(2)
    p2.start
    for (i <- 3 to n) {
     p2 ! sieve(i)
    }
    p2 ! finish(n)
  }
}

object Main {

  var start = System.currentTimeMillis

  def main(args: Array[String]): Unit = {
for (i <- 1 to 10) {
start = System.currentTimeMillis
Generator.generate(i * 20000)
}
  }
}

Akka version

import akka.actor._
import akka.actor.Actor._

case class sieve(n: Int)
case class finish(n: Int)

class SieveAkka(val p: Int) extends Actor {

  var next: ActorRef = null

  def _sieve(n: Int) = {
    if (isPrime(n)) {
      if (next != null) {
        next ! sieve(n)
      } else {
        next = actorOf(new SieveAkka(n))
        next.start
        // println(n + " is prime")
      }
    }
  }

  private def isPrime(n: Int): Boolean = {
    val d = n / p
    val r = n - d * p
    if (r != 0) true else false
  }

  def receive = {
    case sieve(n: Int) => _sieve(n)
    case finish(n: Int) => {
     if (next != null) {
     next ! finish(n)
     } else {
     val time = System.currentTimeMillis - MainAkka.start
     println(n + "," + time)
     // System.exit(0)
     }
    }
    
  }

}

object GeneratorAkka {

  def generate(n: Int): Unit = {
    val p2 = actorOf(new SieveAkka(2))
    p2.start
    for (i <- 3 to n) {
     p2 ! sieve(i)
    }
    p2 ! finish(n)
  }
}

object MainAkka {

var start = System.currentTimeMillis

def main(args: Array[String]): Unit = {
for (i <- 10 to 10) {
start = System.currentTimeMillis
GeneratorAkka.generate(i * 20000)
}
}
}

Then I performed executions of the applications for n = 20`000-200`000. I used a dual core machine with 2GB of main memory. The performance of Akka is quite interesting. I also monitored the executions with VisualVM and it turned out for the execution Akka uses at most 28 threads for all the actors.

Scala vs Akka in prime sievesIt’s very interesting to see how this can be explained that the time for computations gradually converge. I think this is an observation on how Scala/Akka actors are scalable; i.e. when the number of actors increase, the cost of resources/computations are affected in the same order.

Update on 02/21/2012. I took another approach in running the examples. Instead of having a main loop to generate all the prime sieves, each time the program was passed an argument to generate the prime sieves for. It turned out that the results now make more sense, however, I have no idea on how this could change this behavior. A snapshot of the Akka performance is as follows which complies with being close to exponential growth.

Akka performance for prime sieves with N=3.8M

OSGi Runtime Comparison: Eclipse Virgo vs Apache Karaf

I’ve been working for a while on deploying web applications onto an OSGi Runtime. Initially, we had Eclipse Virgo and Apache Karaf as the options. It’s not yet final but I thought maybe it would be nice to post some general comparison in this regard. It also fascinates me that although there are several works on OSGi Runtime/Server, but also in a way or another quite all of them end up in an dependency on or using Apache Felix Framework.

An overview of different OSGi Container Features

Shell FrameworkLogging APIInstance SupportHot DeploymentDynamic ConfigurationProvisioningWeb ContainerAdmin ConsoleOSGi Framework SupportedOSGi Container Runtime
Apache Felix GoGoLogBack?Yes?YesJetty /// Apache Tomcat /// Web Integration Layer (Java EE)YesEclipse EquinoxEclipse Virgo
Apache Felix GoGoLog4J, SLF4J, JCL, etcYesYesYesYesJettyYesEclipse Equinox ///
Apache Felix
Apache Karaf

I shall update the post with more results especially on Eclipse Gyrex if I can grab the time.

Maven repository to OSGi Bundle Repository

Recently, I’ve had the chance to start to work with OSGi. One of the first things that I faces was how I can prepare a local Maven repository as a local OSGi Bundle Repository (OBR). The central concept is to maintain a repository.xml as the OBR descriptor. There are several ways to do so including manually doing it. I just found out that Apache Felix has a Maven plugin called maven-bundle-plugin. In the latest version of this plugin, there is a goal bundle:index. On a project configured with you Maven repository, first configure this plugin and then run:

[plain]
mvn bundle:index
[/plain]

This will generate a repository.xml at the root of your Maven repository. Then you can use that to feed the OSGi container that you use for bundle provisioning.

Safari internal error with Facelets

We had an experience with Safari and Facelets that I thought is nice to share. Using facelet templates, we usually use two tags to define and design the layout: ui:insert and ui:include. The point is that the first one includes the “rendered” output of the inserted template while the second one includes it before rendering. It is typical that a doctype declaration is present at the first line of each XHTML template in facelet. But, in the case ui:include there must no such doctype declaration since it is already defined in the parent template. Firefox does not complain about this but Safari does leading to an internal error message.

Customized WAR/JAR with Maven Multiple Modules

Maven provides a clean way to create multi-module projects such that using the natural style of POM’s will mange the way the final artifacts are bundled and released. However, dealing with non-standard project structure, there are situations that we need to tweak how the project artifacts in a multi-module project are created. In this post, we go through how this is done using Maven Resources Plugin, Maven Jar Plugin, and Maven Dependency Plugin.

The project layout we use is as follows:

  • parent: is the POM project that is the parent of all projects defining the common dependencies and properties
  • foo: is a child project of parent that is for instance provides some architectural API and other resources for other web-based modules
  • bar: is a child project of parent that is a web module dependent on foo and provides some business specific features

In this setup, the final purpose is to build a web archive (war) for bar that selectively uses some features from foo. On the other hand, let’s assume that foo provides three different set of features provided as artifacts:

  • API: a set of classes that is used by other child projects of parent such as bar
  • configs: a set of configuration files and other resources that is needed to deploy when some other child uses foo; e.g. some Spring or Hibernate configuration files in the final artifact
  • web: a set of common web resources that is used by other child projects; e.g. table list templates or common images for web modules

The steps that are required to produce the final bar war artifact are:

  1. We use maven-resources-plugin to copy the resources into the desired locations for being bundles as separate artifacts (foo)
  2. We use maven-jar-plugin to create different artifacts (jar files) such that they can be used independently (foo)
  3. We use maven-dependency-plugin to again include the different artifacts of foo in the desired location to be bundles as a whole war artifact

For the first step, we use maven-resources-plugin to copy for instance the desired resourced into the location that should be considered when packaging the artifacts for foo. We bind the configuration to “prepare-package” phase:

[xml]
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>copy-configs</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/WEB-INF/configs</outputDirectory>
<resources>
<resource>
<directory>src/main/java</directory>
<filtering>true</filtering>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
<execution>
<id>copy-web</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/WEB-INF/views</outputDirectory>
<resources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>**/*.*</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
[/xml]

For the second step, we defined multiple artifact using the “classifier” option in the maven-jar-plugin. This will install different JAR files as the artifacts of foo to be used in dependent projects:

[xml]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>api</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<classifier>api</classifier>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</execution>
<execution>
<id>web</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<classifier>web</classifier>
<includes>
<include>WEB-INF/views/**/*.*</include>
</includes>
</configuration>
</execution>
<execution>
<id>configs</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<classifier>configs</classifier>
<includes>
<include>WEB-INF/configs/**/*.*</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
[/xml]

For the third step, we use maven-dependency-plugin to include and unpack the desired artifacts from foo in the bar packaging process such that the final artifact of bar includes the required resources from foo:

[xml]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>unpack</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>nl.hmsolutions</groupId>
<artifactId>core</artifactId>
<version>1.0</version>
<classifier>web</classifier>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/${project.artifactId}-${project.version}</outputDirectory>
<includes>**/*.*</includes>
</artifactItem>
</artifactItems>
<includes>**/*.*</includes>
<outputDirectory>${project.build.directory}/${project.artifactId}-${project.version}</outputDirectory>
<overWriteReleases>false</overWriteReleases>
</configuration>
</execution>
</executions>
</plugin>
[/xml]

Finally, in the “${basedir}/target/bar-1.0”, we can find the final war archive including all the resources and classes for the project.

برنامه نویسی چند‌هسته‌ای – Multicore Programming

در مسیر پیدا‌کردن موضوعی برای پایان‌نامه‌ی فوق لیسانس، به طور خیلی اتفاقی با موضوعی آشنا شدم به نام برنامه‌نویسی چند‌هسته‌ای که چند سالیه موضوع داغی برای تحقیقات در زمینه‌ی زبان‌های برنامه‌نویسی و تولید و توسعه‌ی نرم‌افزار محسوب می‌شه. این داستان از این‌جا جالبه که ایده‌های برنامه‌نویسی موازی از سال‌ها پیش مطرح بود اما در همون زمان به دلیل نداشتن امکانات سخت‌افزاری و قدرت پردازشی لازم روش‌های برنامه‌نویسی و زبان‌های برنامه‌نویسی با دیدگاه تک‌واحدی بودن پردازنده شروع به رشد کردند. از سال ۲۰۰۰ به بعد که سخت‌افزار‌ها از نظر قدرت پردازشی به شدت پیشرفت کردند و مفهوم چند‌هسته‌ای بودن یک پردازنده الان خیلی عادی می‌آد، چندسالیه که این موضوع قدیمی دوباره به روی میز اومده و خیلی‌ها به دنبال این هستند که چه طور نرم‌افزار باید برای این دوره آماده بشوند.

مقایسه‌ی مشابهی در این زمینه وجود داره که زمانی که ساختار و چارچوب شی‌ءگرا مطرح شده و دنیای نرم‌افزار هم به این سمت رفت که از این ساختار بیشتر استفاده کنه، تاریخ نشون می‌ده که بخشی از موضوع به پیاده‌سازی فرهنگ استفاده از این ساختار مربوط بوده؛ به این معنی زمانی طول کشیده تا برنامه‌نویسان در مرحله اول متقاعد بشوند که این ساختار بهتر از ساختار‌های ساخت‌یافته و قدیمی‌تر بودند و در مرحله این تحول ایجاد شد که تقریباً تمام برنامه‌نویسان از ابتدایی که شروع به فکر و نوشتن برای یک نرم‌افزار می‌کنند، راه‌حل‌ها و ایده‌های خود را در این چارچوب ارائه بدهند. در مورد برنامه‌نویسی چند‌هسته‌ای هم در حال حاضر به نظر می‌آید که این تردید در جامعه‌ی برنامه‌نویس وجود دارد و زمانی طول خواهد کشید تا در آینده با این دیدگاه به سراغ حل مسائل و نوشتن نرم‌افزار بروند.

از سوی دیگر، بررسی راه‌حل‌های موجود نشان می‌دهد که تلاش‌های فراوانی در این زمینه صورت گرفته‌است؛ این تلاش‌های اکثراً یا به شکل زبان‌های جدید مبتنی برزبان‌های شیءگرا هستند یا به شکل کتابخانه‌های تکمیلی برای زبان هدف. نیز، دیدگاه‌های جدیدی هم در این زمینه مطرح‌ شده مانند استفاده از مدل Actor یا Software Transactional Memory که هر دو دارای خوبی‌ها و بدی‌هایی هم هستند.از طرف دیگر، دیدگاه‌های توصیفی (Declarative) در مقابل دستوری (Imperative) هم خود مایه‌ای برای تفاوت در تلاش‌های تحقیقاتی در این زمینه می‌باشد. نکته‌ی جالب این است که تقریباً تمام تحقیقات این موضوع به اتفاق از برنامه‌نویسی وظیفه‌گرا (Functional Programming) حمایت می‌کنند.

یکی از چالش‌های مطرح در این شاخه، انتقال (Migration) سیستم‌های حال حاضر در شرکت‌های بزرگ به بستر‌های چند‌هسته‌ای است. اهمیت این چالش در این است که خیلی‌ها به دنبال روش‌هایی هستند که یا بدون تغییر نرم‌افزار یا با کم‌ترین تغییرات این انتقال بستر را انجام دهند. به همین دلیل، به طور مثال، تلاش‌های خیلی وسیعی در این زمینه بر روی بستر جاوا (Java) انجام شده که به طور مثال این موضوع در زبانی مانند اسکالا (Scala) و با استفاده از Actorها و یا در کتابخانه‌ای مانند Multiverse از طریق Software Transactional Memory مورد تحقیق قرار گرفته‌است. در همین راستا، این موضوع نیز جالب است که زبان‌های برنامه‌نویسی در چه سطحی از دستورالعمل‌ها گرفته تا اشیاء برنامه این فناوری را پشتیبانی می‌کنند که هر کدام کاربرد‌های خود را دارند.

در این زمینه کتابی به نام The Art of Multiprocessor Programming کتابی خوب با محتوای مناسب برای آشنایی عمیق با این موضوعات می‌باشد.

تفاوت حافظه Heap و Stack در Java

بر اساس تعاریف JVM، هر زمانی که یک ریسمان (Thread) شروع به کار می‌کنه، حافظه‌ای بهش تخصص داده می‌شه که که بهش Stack گفته می‌شه. این حافظه متغیر‌ها محلی و نتایج محلی مربوط به ریسمان رو در خودش نگه می‌داره. برای تعیین مقادیر این حافظه از کلید‌های Xms و Xmx استفاده می‌شه. این حافظه در فراخوانی متد‌ها هم مورد استفاده قرار می‌گیره. هنگامی که ریسمان جدیدی درحال شروع باشه یا محاسبات ریسمانی نیاز به حافظه‌ی بیشتر داشته باشه و حد حافظه این امکان رو نده، خطایی که پرتاب می‌شه، StackOverflowError هست.

در طرف دیگه هر زمانی که یک JVM شروع به کار می‌کنه، حافظه‌ای رو در اختیار می‌گیره که درش اشیاء از روی کلاس‌های ساخته می‌شن. این حافظه بین تمام ریسمان‌های JVM مشترکه. برای تنظیم مقادیر این حافظه از کلید‌های XX:PermSize و XX:MaxPermSize استفاده می‌شه. در صورتی که در هنگام محاسبات نیاز به حافظه‌ی بیشتر از حد مجاز باشه، در صورتی که امکان تخصیص وجود نداشته باشه، خطایی دیده می‌شه به نام OutOfMemoryError.