Wednesday, 5 February 2014

Installing Apache Hadoop in Ubuntu Linux

This tutorial covers the installation steps of Apache Hadoop 1.0 and 2.0 in Ubuntu Linux. I will also go through the configuration for running it on pseudo-distributed mode. 


1. Java 6 or later (Hadoop is written in Java)
2. Linux OS (Windows is supported only in development mode. Other flavors of UNIX, including MAC OS can also be used for development)


1. Download the tarball from:

2. Extract the downloaded Hadoop distribution, and export/set the following variables in: ~/.bashrc
export HADOOP_INSTALL=/path/to/your/installation

3.  Set JAVA_HOME in file: $HADOOP_INSTALL/conf/ 

Note: In Hadoop 2.x, this file is located under:  $HADOOP_INSTALL/etc/hadoop/

4.  Check that Hadoop is properly installed by opening up a new shell and executing: 

hadoop version

Installation modes

Hadoop can be run in one of the 3 installation modes: 

1. Standalone (local) mode: This is used for development only. There are no daemons running, everything is in a single JVM. 

2. Pseudo-Distributed mode: Hadoop daemons run on the local machine, simulating a cluster in a single box.

3. Distributed mode: Hadoop daemons run on a cluster of machines.

Configuration for each installation mode

Standalone mode

By default, Hadoop is configured to run on Standalone mode, so no further action is required. 

Pseudo-Distributed mode
1. Component Configuration
Each Hadoop component (core, hdfs, mapreduce) is configured using its own XML file (under the /conf directory for Hadoop 1.x or /etc/hadoop/ for Hadoop 2).
In earlier versions of Hadoop, all configuration was done in a single file hadoop-site.xml, now it's split into 3 different files:
For pseudo-distribution mode, configure the following:


In a pseudo-distributed installation, the entire cluster runs on a single machine, therefore we set the block replication factor to 1 otherwise Hadoop will issue warning messages since it can't replicate data to other physical datanodes. 

When you format (create) an HDFS filesystem, it creates its files in the path specified at property and Subsequently all the filesystem data will be stored in these directories. By default, these properties point to the /tmp directory, so its is strongly advised to change these as all data will be lost if the machine is rebooted.

Set these properties as "final" to make sure they don't get overridden by other configuration files or command line options.


The"mapred.job.tracker" property specifies the address of the jobtracker. It's by default set to "local" which means it will use Hadoop's local job runner to run MapReduce jobs inside a single JVM (development mode)
In Hadoop 2.0 (YARN) the equivalent property is called "" 

                                        If you're using Hadoop 2 (YARN), then set the following additional properties in yarn-site.xml

2. Configuring SSH 

Hadoop makes use of SSH to start its daemons, so you must have SSH installed in your localhost, also, be able to SSH into your host using password-less login (without a password).

Open up a terminal and execute: ssh localhost

if you get a "Connection refused" error, it's because you don't have SSH installed, so install it by running:

sudo apt-get install ssh 

Try again ssh localhost and make sure you don't need to type in a password to connect, if you do, then execute the following to enable password-less login: 

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa 
cat ~/.ssh/ >> ~/.ssh/authorized_keys

3. Formatting the HDFS filesystem

You need to format a brand new HDFS installation before you can use it. Formatting HDFS is easy, just type the following:

hadoop namenode -format

4. Start/Stop Hadoop Daemons:

> Hadoop 1.0:

Start daemons:


NoteIf you get a "JAVA_HOME is not set" error, then make sure you set JAVA_HOME in file:

Check that you have started both, NameNode and Jobtracker daemons by accessing their respective web interfaces:

Jobtracker: http://localhost:50030

Make sure that the "State" on the Jobtracker interface is set to "Running"

Stop daemons: 


> Hadoop 2.0 (MapReduce 2):

Start daemons:


Check that you have started both, NameNode and Resource Manager daemons by accessing their respective web interfaces:

Stop daemons: 


Distributed mode

For a fully-distributed cluster configuration, follow the steps at: 

References (Hadoop: The Definitive Guide, 3rd Edition) 
Same-origin policy (SOP)

Same Origin Policy (SOP) is a web browser security measure that prevents JavasScript running in one site from accessing other sites (unless they're from the same origin). For example, if you have "" open in one browser window and "" in another, then you don't want a script from "" to access your Gmail. Two pages are considered from the same origin if the protocol, port (if any) and host are the same.

Cross-origin resource sharing (CORS)

Cross-origin resource sharing (CORS) is a mechanism that allows scripts to bypass the Same-Origin Policy, essentially allowing JavasScript code to make requests to external sites. Such "cross-domain" requests would otherwise be forbidden by web browsers. When browsers issue requests, they always include the "Origin" header, the server can then pick up this "Origin" header and respond with an "Access-Control-Allow-Origin" header if that Origin is acceptable.  Browsers will then allow the access to go ahead.

CORS in Java

In your Java webapp, all you need to do is set the "Access-Control-Allow-Origin" CORS header to the Servlet response:

response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));

As of Tomcat 7, CORS  support has been added (in the form of a filter). In theory, you can add this Tomcat-specific Servlet to the web.xml and it should take care of adding CORS headers (although that didn't really work for me): 


More info at:

CORS in Scala

If using Spray with Scala, for example, adding CORS headers to the response can be achieved using the following code: 

import spray.http._

path("your_path") {
    _.complete("server response")        

Friday, 31 January 2014

Scala: Remote debugging in SBT's Jetty container

The following will attach your Scala source code to your webapp running in Jetty.

Configuration for remote debugging in SBT's embedded Jetty is not much different Maven's Jetty plugin. Here I used Scala 2.10, SBT 0.12 and dependency "jetty-webapp" 8.1

1. Export JVM debug parameters

$ export SBT_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n"

                   Note: Change parameters "suspend" and "address" to your own needs.

2. Start SBT (sbt) and configure your IDE to connect to the port SBT is listening on. In Eclipse, for example, would be something like this: 

"Run" > "Debug Configurations" > "Remote Java Application"

Create a new configuration and enter the following:

Connection TypeStandard (Socket Attach)

Select "Apply" and then "Debug"

3. Create breakpoints in your code and start the Jetty container: