Monday, December 29, 2014

A simple source code line counter

We sometimes desperately want a tool that will count the total "real" line count of an opensource project or the projects we are working in. It should not count the blank lines and the comments so that we know how big is the code base.

Simpler the tool, better it is. Here is a simple tool (sourcelines.py click here ) I wrote which will do the simple job. Currently it supports C, C++, Java, Scala, Python, PHP and Perl, Go. But you may add other types as well by providing a comment syntax file (explained later).

How do we run the tool? Let us print the helps.
$ python sourcelines.py -h
Usage: sourcelines.py [options]

Options:
  -h, --help            show this help message and exit
  -c COMMENT_FILE, --comment-file=COMMENT_FILE
                        comment syntrax description file
  -d SOURCE_ROOT_DIR, --root-source-dir=SOURCE_ROOT_DIR
                        root directory for source code

An example run for counting the source code lines for Go 1.4
$ python sourcelines.py -d /home/geet/sws/go
File-type:       Go  Line-count:        473968
File-type:       Python  Line-count:       313
File-type:       C  Line-count:          170744
File-type:       C++  Line-count:               7
File-type:       Perl  Line-count:           929

The tool determines the file type by looking at the extension of the files and doesn't do any other magic for that. All the files with extension .pl will be assumed to be Perl files, all the files with extension .java will be assumed to be Java files etc.

Now the tool doesn't know about Haskell files and how Haskell code is commented. It also doesn't know about Javascript files. So, we instruct the tool by providing it a Json file that describes how commenting is done in Haskell and Javascript files.

Below is content from the sample Json file  (let us name it as syntax_haskell_js.json):
{  "hs" : {
        "output_as" : "Haskell",
        "other_extns" : [ "haskell" , "hask" ],
        "start" : "{-",
        "end" : "-}",
        "whole_line" : ["--"]
    },   
    "js" : {
        "output_as" : "Javascript",
        "other_extns" : [ "javascript"],
        "start" : "/*",
        "end" : "*/",
        "whole_line" : ["//"]
    }
}

The Json file describes how the Haskell and Javascript files are commented. The top level keys denote the languages. So, hs and js are denoting Haskell and Javascript languages. Files with extension .hs are output as "Haskell" files.  Also, files with extensions .haskell and .hask will be treated as Haskell files. 
"start" tag denotes the start tag of a comment. For Haskell, it is '{-'. 
"end" tag denotes the end of a comment. For Haskell, it is '-}'.  
"whole_line" tag denotes the commenting tag which indicates the rest of the line to be a comment. For Haskell it is '--', for Javascript it is '//'.

A sample test run output is shown below:
$ python sourcelines.py -d . -c syntax_haskell_js.json
File-type:    Python  Line-count:     173
File-type:   Haskell  Line-count:      49






Sunday, November 30, 2014

Using Zookeeper to coordinate distributed Job watcher

Zookeeper is a tool that can be used for distributed system synchronization, coordination, registry, lock service etc. There are not many open source alternatives to Zookeeper and Zookeeper seems to be pretty good at what it does. That is why many open source projects such as Storm, Kafka use it for service discovery, service registry etc.

In this blog I will explain, how we can use Zookeeper as a coordinator for distributed job watchers.

Let us assume there are processes running on different machines which collect and submits batches (small batches) of works to some queues. There are job executors which polls for the jobs submitted and executes them and submit the results back to the queue. Job watchers keep on monitoring the job statuses and once a job completed they collect the results and do something with the result.
There may be multiple job submitters, watchers and executors. Many instances of job submitters, watchers or executors may come up and go down. The job watchers and executors do a fair sharing of the jobs to watch and execute.  Appearance of new executors or disappearance of existing of executors will trigger re-sharing of the jobs among the executors. Similarly, appearance of disappearance of watchers will trigger re-sharing of watches.

All the above necessitates reliable co-ordination among the different tasks may be executing different machines. Doing the co-ordination correctly is hard as there are too many nuances to address. Fortunately Zookeeper has addressed all of these and it is a proven piece of software that in use for some years now. Let me explain how we can do the co-ordination through zookeeper. (Please refer Zookeeper getting started guide for an overview of Zookeeper if you haven't used it already.)

First, a job watcher has to be notified about the appearance and disappearance of other job watchers. Each watcher while starting up registers themselves under an well known znode /watchers. So, /watchers will have a list of children which are the unique ids of the watcher processes. A child node gets added when a new watcher starts and a child node will disappear when the corresponding watcher process dies, disconnects or loses network connection. Each job watcher sets a watch on the /watchers node and when a watcher process appears or disappears, it gets a notification with list of currently registered watchers ids.




Also, when a watcher chooses to watch a job, it locks that job so as to signal others that they shouldn't spend cycles watching the job it already watching. It will create a lock with the same name under another znode /watchlocks.

The job executors share the jobs to execute. So, whenever a new executor comes up re-sharing of jobs is triggered. Similarly whenever a executor disappears, re-sharing of jobs is again triggered. Each job executors registers themselves under the node /executors and they also put an watch on the znode "/watchers" so that they get notifications for changes in the list of executors currently working.

The executors may not know when a job completes. But the watchers know when a job is complete. This is because when the job submitter submits a job, it submits the job with enough information so that watcher can know when a job is complete. Actually, the executors can also know when a job is complete. But in this example, I am assigning just one responsibility to the executors, which they execute the tasks and submit the results to some results queue.

Whenever watcher detects the completion of a job, it collects the results of the completed job, remove job details from /jobs znode and do something with the result. As a node under /jobs znode is deleted, hence the watcher again re-share the jobs to watch.


This approach gives us the ability to monitor complex workflows. Because there is no reason watcher cannot submit the completed jobs to some other queues which is again executed by the executors. Here I am just giving a very basic example to explain the overall working.

We will use Python for our examples.

We will use Kazoo Zookeeper client.   Install it:
$ sudo pip install kazoo

We will use Redis  as the jobs queue and jobs results queue. We need to install  Redis.
Download Redis from here.
Build Redis.
Extract the downloaded tar archive:
$ tar zxf redis-2.8.17.tar.gz
$ cd redis-2.8.17
$ sudo make
$ sudo make install

Now we install Python redis clients
$ sudo pip install redis
$ sudo pip install hiredis  # Needed for better performance of Python redis client

Let us start Zookeeper server and Redis servers. We will run all run all of them in the same machine as this post is for demonstration purpose only.

$ (zookeeper-install-directory)/bin/zkServer.sh start-foreground
$redis-server



Now let us look at the Python code samples. You may get the complete example in this github link.

I have also pasted the code below:

import sys
from atexit import register
from time import sleep
from random import randint
import logging
import uuid
from redis import ConnectionPool, Redis
from kazoo.client import KazooClient
from math import sqrt
from threading import Thread, Lock, Condition

SUBMITTED = 'subm'
PROCESSED = 'prcd'
ZIPPED = 'zpd'
UPLOADED = 'uploaded'

inited = False

ALLOWED_COMMANDS = ['watcher', 'jobsubmitter', 'jobexecutor']


def state_listener(state):
    print state


def create_path_if_not_exists(zk, path):
    '''
    Create the znode path if it is not existing already
    '''
    if not zk.exists(path):
        try:
            zk.ensure_path(path)
        except Exception as e:
            print e
            return False
    return True


def stop_zk(zkwrapper):
    zkwrapper.stop()


def init_redis():
    '''
    Connect to redis server. For this example, we are running
    Redis on the same machine
    '''
    pool = ConnectionPool(host='localhost', port=6379, db=0)
    r = Redis(connection_pool=pool)
    return r


class zk_wrapper:
    '''
    Callable class wrapping a zookeeper kazooclient object
    '''
    def __init__(self, zk):
        self.zk = zk
        self.state = ''
        register(stop_zk, self)

    def stop(self):
        self.zk.stop()

    def __call__(self, state):
        self.state = state


def init():

    global inited
    zk = None
    try:
        zk = KazooClient(hosts='127.0.0.1:2181')
        zk.add_listener(state_listener)
        zk.start()
        register(stop_zk, zk)
        create_path_if_not_exists(zk, '/jobs')
        create_path_if_not_exists(zk, '/watchers')
        create_path_if_not_exists(zk, '/watchlocks')
        create_path_if_not_exists(zk, '/executors')
    except Exception as e:
        print 'Zk problem ', e
        if zk is not None:
            zk.stop()
        sys.exit(1)

    inited = True
    return zk


class job_watcher:
    def register_myself(self):
        self.zk.create('/watchers/' + self.myid, ephemeral=True)

    def __init__(self):
        self.lock = Lock()
        self.zk = init()
        self.redis = init_redis()
        self.myid = uuid.uuid4().hex
        self.register_myself()
        self.my_jobs = {}
        children = self.zk.get_children('/jobs', watch=self)
        self.alljobs = children
        children = self.zk.get_children('/watchers', watch=self)
        self.watchers = children
        self.myindex = self.watchers.index(self.myid)
        self.num_watchers = len(self.watchers)
        self.lock_my_job_watches()
        self.job_watcher_thread = Thread(target=self, args=[None])
        self.job_watcher_thread.start()

    def unlock_my_jobs(self):
        self.lock.acquire()
        for job, lock in self.my_jobs.items():
            try:
                lock.release()
            except Exception as e:
                print 'Unlocking issue', e
        self.my_jobs.clear()
        self.lock.release()

    def stop_monitoring(self):
        self.stall_monitor = True

    def start_monitoring(self):
        self.stall_monitor = False

    def watch_for_completion(self):
        jobcount = {}
        self.lock.acquire()
        for job in self.my_jobs:
            try:
                vals = self.zk.get('/jobs/' + job)
                stat, count = vals[0].split('=')
                jobcount[job] = {'count': int(count), 'stat': stat}
            except Exception as e:
                print 'Job watch error ', e
                self.lock.release()
                return
        self.lock.release()
        times = 0
        while (not self.stall_monitor) and (times < 4):
            times += 1
            temp = ''
            self.lock.acquire()
            for job in self.my_jobs:
                try:
                    if (job not in jobcount) or jobcount[job]['stat'] != PROCESSED:
                        continue
                    processedcount = self.redis.hlen(job + '_completed')
                    if processedcount == jobcount[job]['count'] or processedcount == 0:
                        self.my_jobs[job].release()
                        self.zk.delete('/watchlocks/' + job)
                        self.redis.delete(job + '_completed')
                        self.zk.delete('/jobs/' + job)
                        print 'Job finished ' + job
                        temp = job
                        break
                except Exception as e:
                    print 'Monitor error ', e
            if temp != '':
                del self.my_jobs[temp]
                sleep(0.4)
            self.lock.release()

    def run(self):
        while True:
            if self.stall_monitor:
                sleep(1)
                continue
            self.watch_for_completion()

    def lock_my_job_watches(self):
        self.stop_monitoring()
        self.unlock_my_jobs()
        self.lock.acquire()
        for child in self.alljobs:
            slot = abs(hash(child)) % self.num_watchers
            if slot != self.myindex:
                continue
            lock = self.zk.Lock('/watchlocks/' + child)
            try:
                if lock.acquire(blocking=True, timeout=1):
                    self.my_jobs[child] = lock
            except Exception as e:
                print 'Lock problem ', e
        self.lock.release()
        if len(self.my_jobs) > 0:
            self.start_monitoring()

    def __call__(self, event):
        if event is None:
            '''
            I am not the zookeeper event callback
            '''
            self.run()
        if event.path == '/jobs':
            children = self.zk.get_children('/jobs', watch=self)
            self.alljobs = children
        else:
            self.watchers = self.zk.get_children('/watchers', watch=self)
            self.num_watchers = len(self.watchers)
            self.myindex = self.watchers.index(self.myid)
        self.lock_my_job_watches()


class job_executor:

    def register_myself(self):
        self.zk.create('/executors/' + self.myid, ephemeral=True)

    def __init__(self):
        zk = init()
        self.zk = zk
        self.lock = Lock()
        self.condition = Condition(self.lock)
        self.some_change = 0
        self.redis = init_redis()
        self.myid = uuid.uuid4().hex
        self.register_myself()
        self.my_jobs = {}
        children = zk.get_children('/jobs', watch=self)
        self.alljobs = children
        children = zk.get_children('/executors', watch=self)
        self.executors = children
        self.myindex = self.executors.index(self.myid)
        self.num_executors = len(self.executors)
        self.keep_running = True
        self.executor_thread = Thread(target=self, args=[None])
        self.executor_thread.start()

    def execute(self):
        self.my_jobs = filter(lambda x: (self.alljobs.index(x) % self.num_executors)
                              == self.myindex, self.alljobs)
        self.execute_jobs()

    def execute_jobs(self):
        some_change = self.some_change

        def isprime(number):
            number = abs(number)
            if number <= 1:
                return False
            if number <= 3:
                return True
            if number & 1 == 0:
                return False
            end = int(sqrt(number))
            i = 3
            while i <= end:
                if number % i == 0:
                    return False
                i += 2
            return True

        if some_change != self.some_change:
            return
        jobs = set()

        for job in self.my_jobs:
            if some_change != self.some_change:
                return
            try:
                jobval = self.zk.get('/jobs/' + job)
                stat, counts = jobval[0].split('=')
                if stat == SUBMITTED:
                    jobs.add(job)
            except Exception as e:
                print 'Problem happened ', e

        while len(jobs) > 0:
            for job in jobs:
                if some_change != self.some_change:
                    return
                try:
                    val = self.redis.lrange(job, 0, 0)
                    if val is None or len(val) == 0:
                        stat = PROCESSED
                        self.zk.set('/jobs/' + job, PROCESSED + '=' + counts)
                        jobs.remove(job)
                        break
                    ival = int(val[0])
                    if self.redis.hmset(job + '_completed', {ival: isprime(ival)}):
                        self.redis.lpop(job)
                except Exception as e:
                    print 'Some problem ', e
                    sys.exit(1)

    def run(self):
        while self.keep_running:
            self.execute()
            self.condition.acquire()
            self.condition.wait(1.0)
            self.condition.release()

    def __call__(self, event):
        if event is None:
            self.run()
        if event.path == '/jobs':
            children = self.zk.get_children('/jobs', watch=self)
            self.alljobs = children
        else:
            self.executors = self.zk.get_children('/executors', watch=self)
            self.num_executors = len(self.executors)
            self.myindex = self.executors.index(self.myid)
        self.some_change += 1
        self.condition.acquire()
        self.condition.notify()
        self.condition.release()


def job_submitter_main():
    try:
        zk = init()
        cpool = ConnectionPool(host='localhost', port=6379, db=0)
        r = Redis(connection_pool=cpool)
        added = 0
        tried = 0
        max_add_try = 5000
        jobname = uuid.uuid4().hex
        added_nums = set()

        while tried < max_add_try:
            value = randint(5000, 90000000)
            tried += 1
            if value not in added_nums:
                added_nums.add(value)
            else:
                continue

            while True:
                try:
                    r.lpush(jobname, value)
                    added += 1
                    break
                except Exception as e:
                    sleep(1)
                    print "Lpush ", jobname, e

        zk = KazooClient(hosts='127.0.0.1:2181')
        zk.add_listener(state_listener)
        zk.start()
        value = SUBMITTED + "=" + str(added)
        zk.create('/jobs/' + jobname, value=value)
        zk.stop()

    except Exception as e:
        print 'Big problem in submitting job ', e
        sys.exit(1)
    print 'Job submitted ' + jobname


def watcher_main():
    job_watcher()


def job_executor_main():
    job_executor()


if __name__ == '__main__':
    if len(sys.argv) < 2:
        print 'Usage: ' + sys.argv[0] + ' command'
        print 'Valid commands are : ' + ', '.join(ALLOWED_COMMANDS)
        sys.exit(1)
    logging.basicConfig()
    if sys.argv[1] not in ALLOWED_COMMANDS:
        print sys.argv[1] + ' not a valid command'
        sys.exit(1)
    if sys.argv[1] == 'watcher':
        watcher_main()
        sleep(86400)
    elif sys.argv[1] == 'jobsubmitter':
        job_submitter_main()
        sleep(2)
    elif sys.argv[1] == 'jobexecutor':
        job_executor_main()
        sleep(86400)

The tasks here are some numbers and the executors checks if the numbers are prime or not. As I said before, this is just for demonstration purpose and hence the tasks are simplest possible tasks, in real life we don't need any distributed environment to check if the numbers are prime. The tasks (i.e. the numbers) are submitted to a queue in Redis in small batches. For the queue, we are just using lists here and hence and hence a job is submitted as a list numbers to a Redis list.

job_submitter_main is the function that submits the job to Redis. It pushes the list of numbers to Redis and also create a job description znode under the node /jobs node in Zookeeper.  The znode name and the name of the list created in Redis are same. The znode created for a job will have the data "subm=count" where count is the number of tasks for the job (so, it will be length of the corresponding list in Zookeeper, let us say it is the job size)

job_watcher is a callable class which watches the /watcher znode and also /jobs znode. All the job_watchers gets a notifications when new job description is created under the /jobs znode. The watchers shares the jobs to watch by following the below algorithm:
Let us say there are N watchers and J is the sorted list of incomplete jobs. All the watchers has the list of currently running registered watchers.  Each watcher sorts the list and find its position within the list. Watcher with position 0 will watch the jobs at index 0, N, 2N, 3N, 4N,....,  watcher with position 1 will watch the jobs at index 1, N + 1, 2N + 1, 3N + 1, 4N + 1, ....  in list J,  watcher will position n will watch the jobs at index n, N +n , 2N + n, 3N + n, 4N + n,  .,.. etc.
The watcher processes create an job_watcher object and start watching the jobs for its completion.

job_executor is the callable class which executes the jobs. The executor processes creates instances of job_executor class and start executing the jobs. The executors share the jobs for execution using a similar algorithm as done by the watchers. An executor completes a task and write the result in a hashmap  in Redis. The hashmap is named as _completed. Each key in the hashmap is a number and the value is 0 or 1. A value of zero indicates the number is not prime, 1 indicates the number is prime. Once a task is completely executed (i,e. the number is checked),  the executor removes the number from the job queue (list) and puts an entry in the hashmap for the result.

The job watchers keep checking size of the completed queues (hashmaps), and once the size becomes equal to the job size it assumes the job is complete. The watcher simply deletes the job node from zookeeper and the _completed hashmap from Redis.

We can run the different components as follows (save the above script in file distjob.py):
To submit jobs:
$ python distjob.py   jobsubmitter
We can submit any number of jobs and we don't really care if the job executors or watchers are running or not.

To run the watchers:
$ python distjob.py  watcher
We can run any number of watchers and we don't care how many job executors or job submitters are running.

To run the job executors:
$ python distjob.py  jobexecutor
We can run any number of job executors and we don't really care how many job submitters or watchers are running.

In this example, to demonstrate distributed job co-ordination using Zookeeper, we are running all the watchers, submitters, executors and Redis server and Zookeeper servers from the same node. But that need not be so. We can easily make it really distributed system. We need to just replace "localhost" with the distributed Zookeeper server list. Also, we also have to use the remote Redis server host or IP whereas in the example script above we are using "localhost" as the Redis server host.










Sunday, October 5, 2014

Docker the lightweight virtual machine on Linux platform

Docker is an open source technology that facilitates the deployment of software in containers by providing operating system-level virtualization and resource isolation. It is a very convenient tool for creating self contained software environments with its own view process tree, memory, network and installed softwares.

It is very lightweight compared the virtual machines while capable of providing a lot of facilities that the virtual machines can offer. For example, let us assume we are developing a real-time-big-data analytics product and we need Elasticsearch, Memcached and Cassandra clusters for our back-end storage. We start prototyping using a single instances for each of these components. Then we start working with real clusters and generally developers will have them installed on
virtual machines (Though we can create the clusters on the same machine by using different ports for each instance, but that is just inconvenient ways to do the things). VMs are generally heavy-weights. What if we can have some lightweight isolated process containers to run each instance of Cassandra or Elasticsearch or Memcached?  Yes, we can use Docker to solve our problem by running them in a "virtually real" distributed world !!


In this post I will explain how we create images for Docker containers and run them on Ubuntu 14.0 platform. But this can be easily mapped to other Linux distributions or other versions of Ubuntu as well.

Let us install Docker (docker.io) software first.

$sudo apt-get update
$sudo apt-get install docker.io

Now let us create a docker image based on Ubuntu 14.04 and add memcached to it. In short we will have a memcached docker images on Ubuntu 14.04.
Let us create a Docker file (Dockerfile) in a directory, say /home/geet/test and put the below lines:

# Dockerfile content
FROM ubuntu:14.04
MAINTAINER "Put your name"
RUN apt-get update
RUN apt-get install -y memcached
ENTRYPOINT ["/usr/bin/memcached" ]
VOLUME [ "/home/geet/sws" ]

The first line "FROM ubuntu:14.04"  specifies a base image ubuntu with tag 14.04. Docker build will look up the image in the current host, and if it cannot find it will download it from Docker hub which is a public Docker image registry.

MAINTAINER specifies the name of the maintainer and can be omitted.
RUN instruction executes the commands (i.e. here it will run "apt-get update" and  "apt-get install -y memcached").

ENTRYPOINT specifies the command to run when we run the image or containers based on the image. Note that memcached will run in foreground and not as a daemon. Because docker container will exit as soon as the command specified in the ENTRYPOINT exits. Hence we will keep the command running in foreground.

VOLUME specifies a list of external directories (in the host machine or other containers) which will be mounted by the container when started.

We create the new docker image issuing the below commands sample:

$ cd /home/geet/test  # this directory has the Dockerfile
$ sudo docker build -t "nipun/memcached:ubuntu14.0"  .

The "-t" option is used to give a name to the new image.

After the build is complete we will get a new image ready to run memcached. Let us check the output of the below commands:

 $ sudo docker images
REPOSITORY           TAG                 IMAGE ID               CREATED           VIRTUAL SIZE
nipun/memcached     ubuntu14.0     7416281a318d       6 hours ago         217.4 MB
ubuntu                      14.04               6b4e8a7373fe        3 days ago          194.9 MB

So, we have two images now and the image  nipun/memcached:nipun/memcached is create successfully.

Now let us run the images
$ sudo docker run -h m1  --name="memcache1" -P nipun/memcached:ubuntu14.0 -u root
#--Press control-C after few seconds
$ sudo docker run -h m2  --name="memcache2" -P nipun/memcached:ubuntu14.0 -u root
#--Press control-C after few seconds 

$ sudo docker run -h m3  --name="memcache3" -P nipun/memcached:ubuntu14.0 -u root
#--Press control-C after few seconds 

-P option is to expose all the ports opened in the container to the host. Memcached listens on port 11211 and because we used -P option, clients running on host will be able to connect to the memcached servers running on the containers.

Now let us run a test to check if our memcached cluster is running fine. We install our favourite python memcached client.

$ sudo docker start memcache1 memcache2 memcache3
$ sudo pip install python-memcached

And run the below script

# script memcache_test.py
#
import memcache

# Pass the list of servers to memcache.Clent API
client = memcache.Client(['172.17.0.5:11211', '172.17.0.6:11211', '172.17.0.7:11211'])
client.set('testkey', 'This is value for the testkey')
val = client.get('testkey')
print val
if val == 'This is value for the testkey' :
    print 'Got correct value. Success!!!!!'
client.disconnect_all()


$python memcache_test.py
The output...
This is value for the testkey
Got correct value. Success!!!!!

So, our pseudo distributed setup for memcached clusters where each memcached server is running in Docker container just worked !!

Thursday, September 4, 2014

Lets ZeroMQ

ZeroMQ is a high performance networking and messaging library. It can carry messages over TCP, multi-cast, in-proc,  inter-process transports. It provides messaging like request-reply, publish-subscribe, push-pull etc. Using these patterns as building blocks, complex messaging systems, execution pipelines can be built. The library is surprisingly easy to use and yet it delivers lightning performance.

In this blog, I will describe how to use ZeroMQ with some very Simple examples. Then I will show  how these building blocks can be used to assemble to build complex systems. At the end I will provide a brief regarding how ZeroMQ works internally.

The examples are in C++, but can be mapped easily to any other languages. ZeroMQ has bindings for more than 40 languages. I will submit python implementation of the same shortly in my github repository.


The built-in ZeroMQ messaging patterns are Request-Reply, Publish-Subscribe, Push-Pull etc.

Requst-Reply

 This pattern connects a set of clients to a set of servers. The service requests from clients get distributed across the servers and the clients may get the response from any of the servers.

A simple example is given below. The client keeps on calling send and recv in a loop while the server keeps on calling recv and send in its loop. The client sends a request, the server receives and process the request and send the response back to the client.



server.cpp

#include <zmq.hpp>
#include <string>
#include <iostream>
int main ()
{
  zmq::context_t context (1);
  zmq::socket_t socket (context, ZMQ_REP);
  socket.bind ("tcp://*:5555");
  int i = 0;
  while (true){
      zmq::message_t request;
      socket.recv (&request);
      std::cout << "Received " << (char *)request.data() << " #times: " << i++ << std::endl;
      zmq::message_t reply (1024);
      memcpy ((void *) reply.data (), "World", 6);
      socket.send (reply);
  }
  socket.close();
  context.close();
  return 0;
}

client.cpp

#include <zmq.hpp>
#include <string>
#include <iostream>

int main ()
{
  zmq::context_t context (1);
  zmq::socket_t socket (context, ZMQ_REQ);
  socket.connect("tcp://127.0.0.1:5555");
  int i  = 0;
  while (true){
      zmq::message_t request (1024);
      memcpy ((void *) request.data (), "Hello", 6);
      socket.send (request);
      zmq::message_t reply;
      socket.recv (&reply);
      std::cout << "Received " << (char *)reply.data() 
          << "#times " << i++  << std::endl;
  }
  socket.close();
  context.close();
  return 0;
}

Here the server is waiting for request in an infinite loop. Whenever it receives a request, it processes the request and send an appropriate response. In this example, the response is always the same, a string "World" !
The client is keeps sending the request in an infinite loop and it always sends the same request "Hello"!
Both the client and server creates a ZeroMQ context.
The server creates a socket of type ZMQ_REP using the context and binds the socket to the transport "tcp://*:5555". This will effectively bind the socket to all the servers' IPs and port 5555. Now the server can recv requests from any number of clients.
The client  connects to server over the TCP transport "tcp://127.0.0.1:5555". Now it can send requests to server and receive responses.

Now let us see how a set of clients can communicate with a set of servers for getting the work done and receiving the status of the work. This is distributed RPC where a set of servers serve a set of clients. The client connects to all the servers and each request is distributed in a round-robin manner to all the servers. Application code does the minimal thing and the ZeroMQ library handle everything transparently.



Slightly modified code is below:
 server_arg_port.cpp
#include <zmq.hpp>
#include <string>
#include <iostream>

using std::cerr;
using std::cout;
using std::endl;

int main (int argc, char *argv[])
{
  if (argc != 2) {
    cerr << argv[0] << " " << "bind-port" << endl;
    exit(1);
  }

  char transport[255] = "";
  zmq::context_t context (1);
  zmq::socket_t socket (context, ZMQ_REP);
  snprintf(transport, 255, "tcp://*:%s", argv[1]);
  socket.bind (transport);

  char response[2048]; 
  memset(response, 0, 2048);
  snprintf(response, 2048, "Response from server lisetning on %s", argv[1]);
  int i = strlen(response);
  int times = 0;
  
  while (true){
      zmq::message_t request;
      socket.recv (&request);
      zmq::message_t reply (2048);
      snprintf(response + i , 2048, " #%d -- request data: %s", 
              times++, (char *)request.data());
      memcpy ((void *) reply.data (), response, strlen(response));
      socket.send (reply);
  }
  socket.close();
  context.close();
  return 0;
}

client_connect_multiple_server.cpp
#include <zmq.hpp>
#include <string>
#include <iostream>
#include <unistd.h>

using std::cerr;
using std::cout;
using std::endl;

int main (int argc, char *argv[])
{
  if (argc < 2){
      cerr << "Usage: " << argv[0] << " server1-port server2-port ... ";
      exit(1);
  }

  zmq::context_t context (1);
  zmq::socket_t socket (context, ZMQ_REQ);

  int i  = 1;
  char transport[128];

  while (i < argc) {
    snprintf(transport, 128, "tcp://127.0.0.1:%s", argv[i++]);
    socket.connect(transport);
  }

  char request_data[1024];
  i = 0;
  while (true){
      zmq::message_t request (1024);
      snprintf(request_data, 1024, "Hello %08d", i++); 
      memcpy ((void *) request.data (), request_data, strlen(request_data));
      socket.send (request);
      zmq::message_t reply;
      socket.recv (&reply);
      cout << "Received " << (char *)reply.data() << endl;
      sleep(1);
  }
  socket.close();
  context.close();
  return 0;
}

As we see, each client connects to a set of servers. Servers are capable of handling multiple clients. Each server actually is capable of handling 1000s of clients. This due to the powerful asynchronus socket communication mechanism ZeroMQ uses internally. On Linux platform it uses epoll, on BSD it uses kqueue that facilitates to create servers capable of handling large number of connections.

Compile and run the above examples as as shown below:
$ g++ -o server_arg server_arg_port.cpp -lzmq
$ g++ -o client_connect_to_many client_connect_multiple_server.cpp -lzmq

Start three servers in the background:
$server_arg 5555 &
$server_arg 5556 &
$server_arg 5557 &

Start a client that connects to all of the servers:
$ ./client_connect_to_many 5555 5556 5557

Sample output from the client is given below. We can see the requests are distributed in round-robin manner among the servers.

Received Response from server lisetning on 5555 #0 -- request data: Hello 00000000
Received Response from server lisetning on 5556 #0 -- request data: Hello 00000001
Received Response from server lisetning on 5557 #0 -- request data: Hello 00000002
Received Response from server lisetning on 5555 #1 -- request data: Hello 00000003
Received Response from server lisetning on 5556 #1 -- request data: Hello 00000004
Received Response from server lisetning on 5557 #1 -- request data: Hello 00000005
Received Response from server lisetning on 5555 #2 -- request data: Hello 00000006
Received Response from server lisetning on 5556 #2 -- request data: Hello 00000007
Received Response from server lisetning on 5557 #2 -- request data: Hello 00000008
Received Response from server lisetning on 5555 #3 -- request data: Hello 00000009
Received Response from server lisetning on 5556 #3 -- request data: Hello 00000010
Received Response from server lisetning on 5557 #3 -- request data: Hello 00000011
Received Response from server lisetning on 5555 #4 -- request data: Hello 00000012

.....

Now let us kill a server process. Then the client will block forever in some send or receive. There is no easy way to recover from the situation. Below is an example of a workaround, but this is also not full-proof. We need to ensure that client or server doesn't issue a recv before a send is satisfied or issue a send before a previous read  is satisfied. Otherwise it will through an exception "Operation cannot be accomplished in current state". Once we restart the particular server again, it will start working fine. But bottom line is if a server which we connected initially goes down, the request-reply pattern doesn't work. I will explain in a later example how to address such problems and make the pattern reliable.

client_connect_multiple_server_timeout.cpp
 
#include <zmq.hpp>
#include <string>
#include <iostream>
#include <unistd.h>

using std::cerr;
using std::cout;
using std::endl;

int main (int argc, char *argv[])
{
  if (argc < 2){
      cerr << "Usage: " << argv[0] << " server1-port server2-port ... ";
      exit(1);
  }

  zmq::context_t context (1);
  zmq::socket_t socket (context, ZMQ_REQ);
  int timeout = 4000;
  socket.setsockopt(ZMQ_SNDTIMEO, &timeout, sizeof(int)); 
  socket.setsockopt(ZMQ_RCVTIMEO, &timeout, sizeof(int)); 

  int i  = 1;
  char transport[128];

  while (i < argc) {
    snprintf(transport, 128, "tcp://127.0.0.1:%s", argv[i++]);
    socket.connect(transport);
  }

  char request_data[1024];
  i = 0;
  while (true){
      do {
        zmq::message_t request (1024);
        snprintf(request_data, 1024, "Hello %08d", i++); 
        memcpy ((void *) request.data (), request_data, strlen(request_data));
        if ( socket.send (request) == false) {
            cout << "Some error in sending request " << endl;
            continue;
        }
        break;
      } while (true);
      do {
        zmq::message_t reply;
        if (socket.recv (&reply) == 0) {
            cout << "Some error in read " << endl;
            continue;
        }
        cout << "Received " << (char *)reply.data() << endl;
        break;
      }while (true);
      sleep(1);
  }
  socket.close();
  context.close();
  return 0;
}

Sunday, January 5, 2014

Java Event Bus with Guava

Sometimes we need to different modules running in a Java process to communicate with each other. Especially threads will communicate or pass messages between them. IPC is never a good option in such scenarios. Message queue within the same process is even less appealing than a linked list.
Also, coding the stuffs ourselves tedious and we should look around to see if somebody already did that and published the same.

Google Guava library is one of the most popular Java library. This also includes the "EventBus" module.  EventBus provides publish-subscribe-style communication between components without requiring the components to explicitly register with one another. Here the publisher and subscribers communicate via the highway, the shared event bus.
The working is simple. We create an EventBus, the subscribers register themselves to the event bus, and the publisher publish or post the "messages" to the event bus. The event bus takes care of delivering the messages to the  appropriate subscribers. There are synchronous and asynchronous  event buses. In synchronous event bus, when a publisher posts a "message",  it will not return till all the subscribers receive the message. In asynchronous event bus, the subscribers are invoked in different threads.

Now let us look at a simple example. There are many publishers who keep publishing the delta of some counters while there is an aggregator which receives the counters and add the delta (It may persist them in database or file etc.)

As the counter publishers and the aggregator will communicate with a common event bus (may be asynchronous or synchronous depending our need, but in most real world cases we generally have to go with asynchronous bus).

Below is the asynchronus event bus provider module:

package geet.example.eventbus;
import java.util.concurrent.Executors;
import com.google.common.eventbus.AsyncEventBus;
import com.google.common.eventbus.EventBus;

public class CounterAsyncEventBus{
 private static EventBus bus = new AsyncEventBus(Executors.newFixedThreadPool(1));
 
 public static EventBus getEventBus(){
  return bus;
 }
}


If we want a synchronous event bus, below is the provider:
package geet.example.eventbus;

import com.google.common.eventbus.EventBus;

public class CounterEventBus{
 private static EventBus bus = new EventBus();
 
 public static EventBus getEventBus(){
  return bus;
 }
}



Below is the Counter class, complex :)
package geet.example.eventbus;

public class Counter {
 private String counterName = null;
 private Integer counterDelta = null;
 public Counter(String counterName, Integer counterDelta) {
  this.counterName = counterName;
  this.counterDelta = counterDelta;
 }
 public String getCounterName() {
  return counterName;
 }
 public void setCounterName(String counterName) {
  this.counterName = counterName;
 }
 public Integer getCounterDelta() {
  return counterDelta;
 }
 public void setCounterDelta(Integer counterDelta) {
  this.counterDelta = counterDelta;
 }
}




Counter Aggregator code is below. The counter aggregator object gets an instance of the common event bus and then registers itself to the event bus. The constructor also takes a boolean flag as an argument which acts an indicator whether to use synchronous or the asynchronous event bus. Also, note the "@Subscribe" annotation which tells that if publisher posts a "Counter", the method "addCount" has to be invoked.

package geet.example.eventbus;

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;

import com.google.common.eventbus.AllowConcurrentEvents;
import com.google.common.eventbus.EventBus;
import com.google.common.eventbus.Subscribe;

public class CounterAggregator {
 private ConcurrentHashMap<String, AtomicInteger> counters = null;
 private EventBus bus = null;

 public CounterAggregator(boolean async) {
  counters = new ConcurrentHashMap<String, AtomicInteger>();
  if (async)
   bus = CounterAsyncEventBus.getEventBus();
  else
   bus = CounterEventBus.getEventBus();
  bus.register(this);
 }

 @Subscribe
 @AllowConcurrentEvents
 public void addCount(Counter counter) {
  Integer val = counter.getCounterDelta();
  String counterName = counter.getCounterName();

  AtomicInteger oldval = counters.putIfAbsent(counterName,
    new AtomicInteger(val));
  if (oldval != null) {
   oldval.addAndGet(val);
  }
  System.out.println(Thread.currentThread().getName()
    + " Value for the counter " + counterName + "="
    + counters.get(counterName));

 }
}




Now below is the code for counter generators. Here also counter generators get the asynchronous or synchronous event bus instance. The "publish" method internally posts Counter objects to the event bus which will be consumed by the subscriber.

package geet.example.eventbus;

import com.google.common.eventbus.EventBus;
public class CounterGenerator {
 private EventBus bus = null;

 public CounterGenerator(boolean async) {
  if (async)
   bus = CounterAsyncEventBus.getEventBus();
  else
   bus = CounterEventBus.getEventBus();
 }

 public void publish(String name, int val) {
  bus.post(new Counter(name, val));
 }

}


Now we have everything set for the event bus demo application. The code is given below. In this example I am showing how to work with asynchronous event bus, but this can easily modified to use synchronous event bus also. It creates a counter generator, a counter aggregator. Counter generator publishes some delta for the counters c1,c2,c3 and c4. The aggregator keeps accumulating the counts. Bottom line is, the event bus elegantly handles the routing of the messages internally saving us from writing a lot of tedious code and reinventing another wheel :)

package geet.example.eventbus;

import java.util.Random;

public class Example {
 public static void main(String[] args) {
  String []counterNames = {"c1", "c2", "c3", "c4" };
  Random random = new Random();
  @SuppressWarnings("unused")
  CounterAggregator aggr = new CounterAggregator(true);
  CounterGenerator gen = new CounterGenerator(true);
  int i = 0;
  while (i++ < 10000){
   gen.publish(counterNames[i & 3], random.nextInt(50000));
  }
 }
}

You may access the all the samples from this github link