final. @param name resource to be added, the classpath is examined for a file with that name.]]> final. @param url url of the resource to be added, the local filesystem is examined directly to find the resource, without referring to the classpath.]]> final. @param file file-path of resource to be added, the local filesystem is examined directly to find the resource, without referring to the classpath.]]> final. @param in InputStream to deserialize the object from.]]> name property, null if no such property exists. Values are processed for variable expansion before being returned. @param name the property name. @return the value of the name property, or null if no such property exists.]]> name property, without doing variable expansion. @param name the property name. @return the value of the name property, or null if no such property exists.]]> value of the name property. @param name property name. @param value property value.]]> name property. If no such property exists, then defaultValue is returned. @param name property name. @param defaultValue default value. @return property value, or defaultValue if the property doesn't exist.]]> name property as an int. If no such property exists, or if the specified value is not a valid int, then defaultValue is returned. @param name property name. @param defaultValue default value. @return property value as an int, or defaultValue.]]> name property to an int. @param name property name. @param value int value of the property.]]> name property as a long. If no such property is specified, or if the specified value is not a valid long, then defaultValue is returned. @param name property name. @param defaultValue default value. @return property value as a long, or defaultValue.]]> name property to a long. @param name property name. @param value long value of the property.]]> name property as a float. If no such property is specified, or if the specified value is not a valid float, then defaultValue is returned. @param name property name. @param defaultValue default value. @return property value as a float, or defaultValue.]]> name property to a float. @param name property name. @param value property value.]]> name property as a boolean. If no such property is specified, or if the specified value is not a valid boolean, then defaultValue is returned. @param name property name. @param defaultValue default value. @return property value as a boolean, or defaultValue.]]> name property to a boolean. @param name property name. @param value boolean value of the property.]]> name property as a collection of Strings. If no such property is specified then empty collection is returned.

This is an optimized version of {@link #getStrings(String)} @param name property name. @return property value as a collection of Strings.]]> name property as an array of Strings. If no such property is specified then null is returned. @param name property name. @return property value as an array of Strings, or null.]]> name property as an array of Strings. If no such property is specified then default value is returned. @param name property name. @param defaultValue The default value @return property value as an array of Strings, or default value.]]> name property as as comma delimited values. @param name property name. @param values The values]]> name property as an array of Class. The value of the property specifies a list of comma separated class names. If no such property is specified, then defaultValue is returned. @param name the property name. @param defaultValue default value. @return property value as a Class[], or defaultValue.]]> name property as a Class. If no such property is specified, then defaultValue is returned. @param name the class name. @param defaultValue default value. @return property value as a Class, or defaultValue.]]> name property as a Class implementing the interface specified by xface. If no such property is specified, then defaultValue is returned. An exception is thrown if the returned class does not implement the named interface. @param name the class name. @param defaultValue default value. @param xface the interface implemented by the named class. @return property value as a Class, or defaultValue.]]> name property to the name of a theClass implementing the given interface xface. An exception is thrown if theClass does not implement the interface xface. @param name property name. @param theClass property value. @param xface the interface implemented by the named class.]]> dirsProp with the given path. If dirsProp contains multiple directories, then one is chosen based on path's hash code. If the selected directory does not exist, an attempt is made to create it. @param dirsProp directory in which to locate the file. @param path file-path. @return local file under the directory with the given path.]]> dirsProp with the given path. If dirsProp contains multiple directories, then one is chosen based on path's hash code. If the selected directory does not exist, an attempt is made to create it. @param dirsProp directory in which to locate the file. @param path file-path. @return local file under the directory with the given path.]]> name. @param name configuration resource name. @return an input stream attached to the resource.]]> name. @param name configuration resource name. @return a reader attached to the resource.]]> String key-value pairs in the configuration. @return an iterator over the entries.]]> true to set quiet-mode on, false to turn it off.]]> Resources

Configurations are specified by resources. A resource contains a set of name/value pairs as XML data. Each resource is named by either a String or by a {@link Path}. If named by a String, then the classpath is examined for a file with that name. If named by a Path, then the local filesystem is examined directly, without referring to the classpath.

Unless explicitly turned off, Hadoop by default specifies two resources, loaded in-order from the classpath:

  1. core-default.xml : Read-only defaults for hadoop.
  2. core-site.xml: Site-specific configuration for a given hadoop installation.
Applications may add additional resources, which are loaded subsequent to these resources in the order they are added.

Final Parameters

Configuration parameters may be declared final. Once a resource declares a value final, no subsequently-loaded resource can alter that value. For example, one might define a final parameter with:

  <property>
    <name>dfs.client.buffer.dir</name>
    <value>/tmp/hadoop/dfs/client</value>
    <final>true</final>
  </property>
Administrators typically define parameters as final in core-site.xml for values that user applications may not alter.

Variable Expansion

Value strings are first processed for variable expansion. The available properties are:

  1. Other properties defined in this Configuration; and, if a name is undefined here,
  2. Properties in {@link System#getProperties()}.

For example, if a configuration resource contains the following property definitions:

  <property>
    <name>basedir</name>
    <value>/user/${user.name}</value>
  </property>
  
  <property>
    <name>tempdir</name>
    <value>${basedir}/tmp</value>
  </property>
When conf.get("tempdir") is called, then ${basedir} will be resolved to another property in this Configuration, while ${user.name} would then ordinarily be resolved to the value of the System property with that name.]]>
DistributedCache is a facility provided by the Map-Reduce framework to cache files (text, archives, jars etc.) needed by applications.

Applications specify the files, via urls (hdfs:// or http://) to be cached via the {@link org.apache.hadoop.mapred.JobConf}. The DistributedCache assumes that the files specified via hdfs:// urls are already present on the {@link FileSystem} at the path specified by the url.

The framework will copy the necessary files on to the slave node before any tasks for the job are executed on that node. Its efficiency stems from the fact that the files are only copied once per job and the ability to cache archives which are un-archived on the slaves.

DistributedCache can be used to distribute simple, read-only data/text files and/or more complex types such as archives, jars etc. Archives (zip, tar and tgz/tar.gz files) are un-archived at the slave nodes. Jars may be optionally added to the classpath of the tasks, a rudimentary software distribution mechanism. Files have execution permissions. Optionally users can also direct it to symlink the distributed cache file(s) into the working directory of the task.

DistributedCache tracks modification timestamps of the cache files. Clearly the cache files should not be modified by the application or externally while the job is executing.

Here is an illustrative example on how to use the DistributedCache:

     // Setting up the cache for the application
     
     1. Copy the requisite files to the FileSystem:
     
     $ bin/hadoop fs -copyFromLocal lookup.dat /myapp/lookup.dat  
     $ bin/hadoop fs -copyFromLocal map.zip /myapp/map.zip  
     $ bin/hadoop fs -copyFromLocal mylib.jar /myapp/mylib.jar
     $ bin/hadoop fs -copyFromLocal mytar.tar /myapp/mytar.tar
     $ bin/hadoop fs -copyFromLocal mytgz.tgz /myapp/mytgz.tgz
     $ bin/hadoop fs -copyFromLocal mytargz.tar.gz /myapp/mytargz.tar.gz
     
     2. Setup the application's JobConf:
     
     JobConf job = new JobConf();
     DistributedCache.addCacheFile(new URI("/myapp/lookup.dat#lookup.dat"), 
                                   job);
     DistributedCache.addCacheArchive(new URI("/myapp/map.zip", job);
     DistributedCache.addFileToClassPath(new Path("/myapp/mylib.jar"), job);
     DistributedCache.addCacheArchive(new URI("/myapp/mytar.tar", job);
     DistributedCache.addCacheArchive(new URI("/myapp/mytgz.tgz", job);
     DistributedCache.addCacheArchive(new URI("/myapp/mytargz.tar.gz", job);
     
     3. Use the cached files in the {@link org.apache.hadoop.mapred.Mapper}
     or {@link org.apache.hadoop.mapred.Reducer}:
     
     public static class MapClass extends MapReduceBase  
     implements Mapper<K, V, K, V> {
     
       private Path[] localArchives;
       private Path[] localFiles;
       
       public void configure(JobConf job) {
         // Get the cached archives/files
         localArchives = DistributedCache.getLocalCacheArchives(job);
         localFiles = DistributedCache.getLocalCacheFiles(job);
       }
       
       public void map(K key, V value, 
                       OutputCollector<K, V> output, Reporter reporter) 
       throws IOException {
         // Use data from the cached archives/files here
         // ...
         // ...
         output.collect(k, v);
       }
     }
     
 

@see org.apache.hadoop.mapred.JobConf @see org.apache.hadoop.mapred.JobClient]]>
BufferedFSInputStream with the specified buffer size, and saves its argument, the input stream in, for later use. An internal buffer array of length size is created and stored in buf. @param in the underlying input stream. @param size the buffer size. @exception IllegalArgumentException if size <= 0.]]> setReplication of FileSystem @param src file name @param replication new replication @throws IOException @return true if successful; false if file does not exist or is a directory]]> fs.scheme.class whose value names the FileSystem class. The entire URI is passed to the FileSystem instance's initialize method.]]> Return all the files that match filePattern and are not checksum files. Results are sorted by their names.

A filename pattern is composed of regular characters and special pattern matching characters, which are:

?
Matches any single character.

*
Matches zero or more characters.

[abc]
Matches a single character from character set {a,b,c}.

[a-b]
Matches a single character from the character range {a...b}. Note that character a must be lexicographically less than or equal to character b.

[^a]
Matches a single character that is not from character set or range {a}. Note that the ^ character must occur immediately to the right of the opening bracket.

\c
Removes (escapes) any special meaning of character c.

{ab,cd}
Matches a string from the string set {ab, cd}

{ab,c{de,fh}}
Matches a string from the string set {ab, cde, cfh}
@param pathPattern a regular expression specifying a pth pattern @return an array of paths that match the path pattern @throws IOException]]>
All user code that may potentially use the Hadoop Distributed File System should be written to use a FileSystem object. The Hadoop DFS is a multi-machine system that appears as a single disk. It's useful because of its fault tolerance and potentially very large capacity.

The local implementation is {@link LocalFileSystem} and distributed implementation is DistributedFileSystem.]]> FilterFileSystem contains some other file system, which it uses as its basic file system, possibly transforming the data along the way or providing additional functionality. The class FilterFileSystem itself simply overrides all methods of FileSystem with versions that pass all requests to the contained file system. Subclasses of FilterFileSystem may further override some of these methods and may also provide additional methods and fields.]]> buf at offset and checksum into checksum. The method is used for implementing read, therefore, it should be optimized for sequential reading @param pos chunkPos @param buf desitination buffer @param offset offset in buf at which to store data @param len maximun number of bytes to read @return number of bytes read]]> -1 if the end of the stream is reached. @exception IOException if an I/O error occurs.]]> This method implements the general contract of the corresponding {@link InputStream#read(byte[], int, int) read} method of the {@link InputStream} class. As an additional convenience, it attempts to read as many bytes as possible by repeatedly invoking the read method of the underlying stream. This iterated read continues until one of the following conditions becomes true:

  • The specified number of bytes have been read,
  • The read method of the underlying stream returns -1, indicating end-of-file.
If the first read on the underlying stream returns -1 to indicate end-of-file then this method returns -1. Otherwise this method returns the number of bytes actually read. @param b destination buffer. @param off offset at which to start storing bytes. @param len maximum number of bytes to read. @return the number of bytes read, or -1 if the end of the stream has been reached. @exception IOException if an I/O error occurs. ChecksumException if any checksum error occurs]]>
n bytes of data from the input stream.

This method may skip more bytes than are remaining in the backing file. This produces no exception and the number of bytes skipped may include some number of bytes that were beyond the EOF of the backing file. Attempting to read from the stream after skipping past the end will result in -1 indicating the end of the file.

If n is negative, no bytes are skipped. @param n the number of bytes to be skipped. @return the actual number of bytes skipped. @exception IOException if an I/O error occurs. ChecksumException if the chunk to skip to is corrupted]]> This method may seek past the end of the file. This produces no exception and an attempt to read from the stream will result in -1 indicating the end of the file. @param pos the postion to seek to. @exception IOException if an I/O error occurs. ChecksumException if the chunk to seek to is corrupted]]> len bytes from stm @param stm an input stream @param buf destiniation buffer @param offset offset at which to store data @param len number of bytes to read @return actual number of bytes read @throws IOException if there is any IO error]]> len bytes from the specified byte array starting at offset off and generate a checksum for each data chunk.

This method stores bytes from the given array into this stream's buffer before it gets checksumed. The buffer gets checksumed and flushed to the underlying output stream when all data in a checksum chunk are in the buffer. If the buffer is empty and requested length is at least as large as the size of next checksum chunk size, this method will checksum and write the chunk directly to the underlying output stream. Thus it avoids uneccessary data copy. @param b the data. @param off the start offset in the data. @param len the number of bytes to write. @exception IOException if an I/O error occurs.]]> true if and only if pathname should be included]]> trash feature. Files are moved to a user's trash directory, a subdirectory of their home directory named ".Trash". Files are initially moved to a current sub-directory of the trash directory. Within that sub-directory their original path is preserved. Periodically one may checkpoint the current trash and remove older checkpoints. (This design permits trash management without enumeration of the full trash content, without date support in the filesystem, and without clock synchronization.)]]> A {@link FileSystem} backed by an FTP client provided by Apache Commons Net.

]]>
A client for the Kosmos filesystem (KFS)

Introduction

This pages describes how to use Kosmos Filesystem ( KFS ) as a backing store with Hadoop. This page assumes that you have downloaded the KFS software and installed necessary binaries as outlined in the KFS documentation.

Steps

  • In the Hadoop conf directory edit core-site.xml, add the following:
    <property>
      <name>fs.kfs.impl</name>
      <value>org.apache.hadoop.fs.kfs.KosmosFileSystem</value>
      <description>The FileSystem for kfs: uris.</description>
    </property>
                
  • In the Hadoop conf directory edit core-site.xml, adding the following (with appropriate values for <server> and <port>):
    <property>
      <name>fs.default.name</name>
      <value>kfs://<server:port></value> 
    </property>
    
    <property>
      <name>fs.kfs.metaServerHost</name>
      <value><server></value>
      <description>The location of the KFS meta server.</description>
    </property>
    
    <property>
      <name>fs.kfs.metaServerPort</name>
      <value><port></value>
      <description>The location of the meta server's port.</description>
    </property>
    
    
  • Copy KFS's kfs-0.1.jar to Hadoop's lib directory. This step enables Hadoop's to load the KFS specific modules. Note that, kfs-0.1.jar was built when you compiled KFS source code. This jar file contains code that calls KFS's client library code via JNI; the native code is in KFS's libkfsClient.so library.
  • When the Hadoop map/reduce trackers start up, those processes (on local as well as remote nodes) will now need to load KFS's libkfsClient.so library. To simplify this process, it is advisable to store libkfsClient.so in an NFS accessible directory (similar to where Hadoop binaries/scripts are stored); then, modify Hadoop's conf/hadoop-env.sh adding the following line and providing suitable value for <path>:
    export LD_LIBRARY_PATH=<path>
    
  • Start only the map/reduce trackers
    example: execute Hadoop's bin/start-mapred.sh

If the map/reduce job trackers start up, all file-I/O is done to KFS.]]>
(cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause). @param cause the cause (which is saved for later retrieval by the {@link #getCause()} method). (A null value is permitted, and indicates that the cause is nonexistent or unknown.)]]> This class is a tool for migrating data from an older to a newer version of an S3 filesystem.

All files in the filesystem are migrated by re-writing the block metadata - no datafiles are touched.

]]>
Extracts AWS credentials from the filesystem URI or configuration.

]]>
A block-based {@link FileSystem} backed by Amazon S3.

@see NativeS3FileSystem]]>
A distributed, block-based implementation of {@link org.apache.hadoop.fs.FileSystem} that uses Amazon S3 as a backing store.

Files are stored in S3 as blocks (represented by {@link org.apache.hadoop.fs.s3.Block}), which have an ID and a length. Block metadata is stored in S3 as a small record (represented by {@link org.apache.hadoop.fs.s3.INode}) using the URL-encoded path string as a key. Inodes record the file type (regular file or directory) and the list of blocks. This design makes it easy to seek to any given position in a file by reading the inode data to compute which block to access, then using S3's support for HTTP Range headers to start streaming from the correct position. Renames are also efficient since only the inode is moved (by a DELETE followed by a PUT since S3 does not support renames).

For a single file /dir1/file1 which takes two blocks of storage, the file structure in S3 would be something like this:

/
/dir1
/dir1/file1
block-6415776850131549260
block-3026438247347758425

Inodes start with a leading /, while blocks are prefixed with block-.

]]>
If f is a file, this method will make a single call to S3. If f is a directory, this method will make a maximum of (n / 1000) + 2 calls to S3, where n is the total number of files and directories contained directly in f.

]]>
A {@link FileSystem} for reading and writing files stored on Amazon S3. Unlike {@link org.apache.hadoop.fs.s3.S3FileSystem} this implementation stores files on S3 in their native form so they can be read by other S3 tools.

@see org.apache.hadoop.fs.s3.S3FileSystem]]>
A distributed implementation of {@link org.apache.hadoop.fs.FileSystem} for reading and writing files on Amazon S3. Unlike {@link org.apache.hadoop.fs.s3.S3FileSystem}, which is block-based, this implementation stores files on S3 in their native form for interoperability with other S3 tools.

]]>
. @param name The name of the server @param port The port to use on the server @param findPort whether the server should start at the given port and increment by 1 until it finds a free port. @param conf Configuration]]> points to the log directory "/static/" -> points to common static files (src/webapps/static) "/" -> the jsp server code from (src/webapps/)]]> nth value.]]> nth value in the file.]]> public class IntArrayWritable extends ArrayWritable { public IntArrayWritable() { super(IntWritable.class); } } ]]> o is a ByteWritable with the same value.]]> This saves memory over creating a new DataInputStream and ByteArrayInputStream each time data is read.

Typical usage is something like the following:


 DataInputBuffer buffer = new DataInputBuffer();
 while (... loop condition ...) {
   byte[] data = ... get data ...;
   int dataLength = ... get data length ...;
   buffer.reset(data, dataLength);
   ... read buffer using DataInput methods ...
 }
 
]]>
This saves memory over creating a new DataOutputStream and ByteArrayOutputStream each time data is written.

Typical usage is something like the following:


 DataOutputBuffer buffer = new DataOutputBuffer();
 while (... loop condition ...) {
   buffer.reset();
   ... write buffer using DataOutput methods ...
   byte[] data = buffer.getData();
   int dataLength = buffer.getLength();
   ... write data to its ultimate destination ...
 }
 
]]>
the class of the item @param conf the configuration to store @param item the object to be stored @param keyName the name of the key to use @throws IOException : forwards Exceptions from the underlying {@link Serialization} classes.]]> the class of the item @param conf the configuration to use @param keyName the name of the key to use @param itemClass the class of the item @return restored object @throws IOException : forwards Exceptions from the underlying {@link Serialization} classes.]]> the class of the item @param conf the configuration to use @param items the objects to be stored @param keyName the name of the key to use @throws IndexOutOfBoundsException if the items array is empty @throws IOException : forwards Exceptions from the underlying {@link Serialization} classes.]]> the class of the item @param conf the configuration to use @param keyName the name of the key to use @param itemClass the class of the item @return restored object @throws IOException : forwards Exceptions from the underlying {@link Serialization} classes.]]> DefaultStringifier offers convenience methods to store/load objects to/from the configuration. @param the class of the objects to stringify]]> o is a DoubleWritable with the same value.]]> o is a FloatWritable with the same value.]]> When two sequence files, which have same Key type but different Value types, are mapped out to reduce, multiple Value types is not allowed. In this case, this class can help you wrap instances with different types.

Compared with ObjectWritable, this class is much more effective, because ObjectWritable will append the class declaration as a String into the output file in every Key-Value pair.

Generic Writable implements {@link Configurable} interface, so that it will be configured by the framework. The configuration is passed to the wrapped objects implementing {@link Configurable} interface before deserialization.

how to use it:
1. Write your own class, such as GenericObject, which extends GenericWritable.
2. Implements the abstract method getTypes(), defines the classes which will be wrapped in GenericObject in application. Attention: this classes defined in getTypes() method, must implement Writable interface.

The code looks like this:
 public class GenericObject extends GenericWritable {
 
   private static Class[] CLASSES = {
               ClassType1.class, 
               ClassType2.class,
               ClassType3.class,
               };

   protected Class[] getTypes() {
       return CLASSES;
   }

 }
 
@since Nov 8, 2006]]>
This saves memory over creating a new InputStream and ByteArrayInputStream each time data is read.

Typical usage is something like the following:


 InputBuffer buffer = new InputBuffer();
 while (... loop condition ...) {
   byte[] data = ... get data ...;
   int dataLength = ... get data length ...;
   buffer.reset(data, dataLength);
   ... read buffer using InputStream methods ...
 }
 
@see DataInputBuffer @see DataOutput]]>
o is a IntWritable with the same value.]]> closes the input and output streams at the end. @param in InputStrem to read from @param out OutputStream to write to @param conf the Configuration object]]> ignore any {@link IOException} or null pointers. Must only be used for cleanup in exception handlers. @param log the log to record problems to at debug level. Can be null. @param closeables the objects to close]]> o is a LongWritable with the same value.]]> A map is a directory containing two files, the data file, containing all keys and values in the map, and a smaller index file, containing a fraction of the keys. The fraction is determined by {@link Writer#getIndexInterval()}.

The index file is read entirely into memory. Thus key implementations should try to keep themselves small.

Map files are created by adding entries in-order. To maintain a large database, perform updates by copying the previous version of a database and merging in a sorted change list, to create a new version of the database in a new file. Sorting large change lists can be done with {@link SequenceFile.Sorter}.]]> key and val. Returns true if such a pair exists and false when at the end of the map]]> key or if it does not exist, at the first entry after the named key. - * @param key - key that we're trying to find - * @param val - data value if key is found - * @return - the key that was the closest match or null if eof.]]> key does not exist, return the first entry that falls just before the key. Otherwise, return the record that sorts just after. @return - the key that was the closest match or null if eof.]]> o is an MD5Hash whose digest contains the same values.]]> This saves memory over creating a new OutputStream and ByteArrayOutputStream each time data is written.

Typical usage is something like the following:


 OutputBuffer buffer = new OutputBuffer();
 while (... loop condition ...) {
   buffer.reset();
   ... write buffer using OutputStream methods ...
   byte[] data = buffer.getData();
   int dataLength = buffer.getLength();
   ... write data to its ultimate destination ...
 }
 
@see DataOutputBuffer @see InputBuffer]]>
A {@link Comparator} that operates directly on byte representations of objects.

@param @see DeserializerComparator]]>
SequenceFiles are flat files consisting of binary key/value pairs.

SequenceFile provides {@link Writer}, {@link Reader} and {@link Sorter} classes for writing, reading and sorting respectively.

There are three SequenceFile Writers based on the {@link CompressionType} used to compress key/value pairs:
  1. Writer : Uncompressed records.
  2. RecordCompressWriter : Record-compressed files, only compress values.
  3. BlockCompressWriter : Block-compressed files, both keys & values are collected in 'blocks' separately and compressed. The size of the 'block' is configurable.

The actual compression algorithm used to compress key and/or values can be specified by using the appropriate {@link CompressionCodec}.

The recommended way is to use the static createWriter methods provided by the SequenceFile to chose the preferred format.

The {@link Reader} acts as the bridge and can read any of the above SequenceFile formats.

SequenceFile Formats

Essentially there are 3 different formats for SequenceFiles depending on the CompressionType specified. All of them share a common header described below.

  • version - 3 bytes of magic header SEQ, followed by 1 byte of actual version number (e.g. SEQ4 or SEQ6)
  • keyClassName -key class
  • valueClassName - value class
  • compression - A boolean which specifies if compression is turned on for keys/values in this file.
  • blockCompression - A boolean which specifies if block-compression is turned on for keys/values in this file.
  • compression codec - CompressionCodec class which is used for compression of keys and/or values (if compression is enabled).
  • metadata - {@link Metadata} for this file.
  • sync - A sync marker to denote end of the header.
Uncompressed SequenceFile Format
  • Header
  • Record
    • Record length
    • Key length
    • Key
    • Value
  • A sync-marker every few 100 bytes or so.
Record-Compressed SequenceFile Format
  • Header
  • Record
    • Record length
    • Key length
    • Key
    • Compressed Value
  • A sync-marker every few 100 bytes or so.
Block-Compressed SequenceFile Format
  • Header
  • Record Block
    • Compressed key-lengths block-size
    • Compressed key-lengths block
    • Compressed keys block-size
    • Compressed keys block
    • Compressed value-lengths block-size
    • Compressed value-lengths block
    • Compressed values block-size
    • Compressed values block
  • A sync-marker every few 100 bytes or so.

The compressed blocks of key lengths and value lengths consist of the actual lengths of individual keys/values encoded in ZeroCompressedInteger format.

@see CompressionCodec]]>
key, skipping its value. True if another entry exists, and false at end of file.]]> key and val. Returns true if such a pair exists and false when at end of file]]> The position passed must be a position returned by {@link SequenceFile.Writer#getLength()} when writing this file. To seek to an arbitrary position, use {@link SequenceFile.Reader#sync(long)}.]]> SegmentDescriptor @param segments the list of SegmentDescriptors @param tmpDir the directory to write temporary files into @return RawKeyValueIterator @throws IOException]]> For best performance, applications should make sure that the {@link Writable#readFields(DataInput)} implementation of their keys is very efficient. In particular, it should avoid allocating memory.]]> This always returns a synchronized position. In other words, immediately after calling {@link SequenceFile.Reader#seek(long)} with a position returned by this method, {@link SequenceFile.Reader#next(Writable)} may be called. However the key may be earlier in the file than key last written when this method was called (e.g., with block-compression, it may be the first key in the block that was being written when this method was called).]]> key. Returns true if such a key exists and false when at the end of the set.]]> key. Returns key, or null if no match exists.]]> the class of the objects to stringify]]> position. Note that this method avoids using the converter or doing String instatiation @return the Unicode scalar value at position or -1 if the position is invalid or points to a trailing byte]]> what in the backing buffer, starting as position start. The starting position is measured in bytes and the return value is in terms of byte position in the buffer. The backing buffer is not converted to a string for this operation. @return byte position of the first occurence of the search string in the UTF-8 buffer or -1 if not found]]> o is a Text with the same contents.]]> replace is true, then malformed input is replaced with the substitution character, which is U+FFFD. Otherwise the method throws a MalformedInputException.]]> replace is true, then malformed input is replaced with the substitution character, which is U+FFFD. Otherwise the method throws a MalformedInputException. @return ByteBuffer: bytes stores at ByteBuffer.array() and length is ByteBuffer.limit()]]> In addition, it provides methods for string traversal without converting the byte array to a string.

Also includes utilities for serializing/deserialing a string, coding/decoding a string, checking if a byte array contains valid UTF8 code, calculating the length of an encoded string.]]> o is a UTF8 with the same contents.]]> Also includes utilities for efficiently reading and writing UTF-8. @deprecated replaced by Text]]> This is useful when a class may evolve, so that instances written by the old version of the class may still be processed by the new version. To handle this situation, {@link #readFields(DataInput)} implementations should catch {@link VersionMismatchException}.]]> o is a VIntWritable with the same value.]]> o is a VLongWritable with the same value.]]> out. @param out DataOuput to serialize this object into. @throws IOException]]> in.

For efficiency, implementations should attempt to re-use storage in the existing object where possible.

@param in DataInput to deseriablize this object from. @throws IOException]]>
Any key or value type in the Hadoop Map-Reduce framework implements this interface.

Implementations typically implement a static read(DataInput) method which constructs a new instance, calls {@link #readFields(DataInput)} and returns the instance.

Example:

     public class MyWritable implements Writable {
       // Some data     
       private int counter;
       private long timestamp;
       
       public void write(DataOutput out) throws IOException {
         out.writeInt(counter);
         out.writeLong(timestamp);
       }
       
       public void readFields(DataInput in) throws IOException {
         counter = in.readInt();
         timestamp = in.readLong();
       }
       
       public static MyWritable read(DataInput in) throws IOException {
         MyWritable w = new MyWritable();
         w.readFields(in);
         return w;
       }
     }
 

]]>
WritableComparables can be compared to each other, typically via Comparators. Any type which is to be used as a key in the Hadoop Map-Reduce framework should implement this interface.

Example:

     public class MyWritableComparable implements WritableComparable {
       // Some data
       private int counter;
       private long timestamp;
       
       public void write(DataOutput out) throws IOException {
         out.writeInt(counter);
         out.writeLong(timestamp);
       }
       
       public void readFields(DataInput in) throws IOException {
         counter = in.readInt();
         timestamp = in.readLong();
       }
       
       public int compareTo(MyWritableComparable w) {
         int thisValue = this.value;
         int thatValue = ((IntWritable)o).value;
         return (thisValue < thatValue ? -1 : (thisValue==thatValue ? 0 : 1));
       }
     }
 

]]>
The default implementation reads the data into two {@link WritableComparable}s (using {@link Writable#readFields(DataInput)}, then calls {@link #compare(WritableComparable,WritableComparable)}.]]> The default implementation uses the natural ordering, calling {@link Comparable#compareTo(Object)}.]]> This base implemenation uses the natural ordering. To define alternate orderings, override {@link #compare(WritableComparable,WritableComparable)}.

One may optimize compare-intensive operations by overriding {@link #compare(byte[],int,int,byte[],int,int)}. Static utility methods are provided to assist in optimized implementations of this method.]]> Enum type @param in DataInput to read from @param enumType Class type of Enum @return Enum represented by String read from DataInput @throws IOException]]> len number of bytes in input streamin @param in input stream @param len number of bytes to skip @throws IOException when skipped less number of bytes]]> CompressionCodec for which to get the Compressor @return Compressor for the given CompressionCodec from the pool or a new one]]> CompressionCodec for which to get the Decompressor @return Decompressor for the given CompressionCodec the pool or a new one]]> Compressor to be returned to the pool]]> Decompressor to be returned to the pool]]> Implementations are assumed to be buffered. This permits clients to reposition the underlying input stream then call {@link #resetState()}, without having to also synchronize client buffers.]]> true indicating that more input data is required. @param b Input data @param off Start offset @param len Length]]> true if the input data buffer is empty and #setInput() should be called in order to provide more input.]]> true if the end of the compressed data output stream has been reached.]]> true indicating that more input data is required. @param b Input data @param off Start offset @param len Length]]> true if the input data buffer is empty and #setInput() should be called in order to provide more input.]]> true if a preset dictionary is needed for decompression. @return true if a preset dictionary is needed for decompression]]> true if the end of the compressed data output stream has been reached.]]> FIXME: This array should be in a private or package private location, since it could be modified by malicious code.

]]>
This interface is public for historical purposes. You should have no need to use it.

]]>
Although BZip2 headers are marked with the magic "Bz" this constructor expects the next byte in the stream to be the first one after the magic. Thus callers have to skip the first two bytes. Otherwise this constructor will throw an exception.

@throws IOException if the stream content is malformed or an I/O error occurs. @throws NullPointerException if in == null]]>
The decompression requires large amounts of memory. Thus you should call the {@link #close() close()} method as soon as possible, to force CBZip2InputStream to release the allocated memory. See {@link CBZip2OutputStream CBZip2OutputStream} for information about memory usage.

CBZip2InputStream reads bytes from the compressed source stream via the single byte {@link java.io.InputStream#read() read()} method exclusively. Thus you should consider to use a buffered source stream.

Instances of this class are not threadsafe.

]]>
CBZip2OutputStream with a blocksize of 900k.

Attention: The caller is resonsible to write the two BZip2 magic bytes "BZ" to the specified stream prior to calling this constructor.

@param out * the destination stream. @throws IOException if an I/O error occurs in the specified stream. @throws NullPointerException if out == null.]]>
CBZip2OutputStream with specified blocksize.

Attention: The caller is resonsible to write the two BZip2 magic bytes "BZ" to the specified stream prior to calling this constructor.

@param out the destination stream. @param blockSize the blockSize as 100k units. @throws IOException if an I/O error occurs in the specified stream. @throws IllegalArgumentException if (blockSize < 1) || (blockSize > 9). @throws NullPointerException if out == null. @see #MIN_BLOCKSIZE @see #MAX_BLOCKSIZE]]>
inputLength this method returns MAX_BLOCKSIZE always. @param inputLength The length of the data which will be compressed by CBZip2OutputStream.]]> == 1.]]> == 9.]]> If you are ever unlucky/improbable enough to get a stack overflow whilst sorting, increase the following constant and try again. In practice I have never seen the stack go above 27 elems, so the following limit seems very generous.

]]>
The compression requires large amounts of memory. Thus you should call the {@link #close() close()} method as soon as possible, to force CBZip2OutputStream to release the allocated memory.

You can shrink the amount of allocated memory and maybe raise the compression speed by choosing a lower blocksize, which in turn may cause a lower compression ratio. You can avoid unnecessary memory allocation by avoiding using a blocksize which is bigger than the size of the input.

You can compute the memory usage for compressing by the following formula:

 <code>400k + (9 * blocksize)</code>.
 

To get the memory required for decompression by {@link CBZip2InputStream CBZip2InputStream} use

 <code>65k + (5 * blocksize)</code>.
 
Memory usage by blocksize
Blocksize Compression
memory usage
Decompression
memory usage
100k 1300k 565k
200k 2200k 1065k
300k 3100k 1565k
400k 4000k 2065k
500k 4900k 2565k
600k 5800k 3065k
700k 6700k 3565k
800k 7600k 4065k
900k 8500k 4565k

For decompression CBZip2InputStream allocates less memory if the bzipped input is smaller than one block.

Instances of this class are not threadsafe.

TODO: Update to BZip2 1.0.1

]]>
@return the total (non-negative) number of uncompressed bytes input so far]]> @return the total (non-negative) number of uncompressed bytes input so far]]> true if native-zlib is loaded & initialized and can be loaded for this job, else false]]> Keep trying a limited number of times, waiting a fixed time between attempts, and then fail by re-throwing the exception.

]]>
Keep trying for a maximum time, waiting a fixed time between attempts, and then fail by re-throwing the exception.

]]>
Keep trying a limited number of times, waiting a growing amount of time between attempts, and then fail by re-throwing the exception. The time between attempts is sleepTime mutliplied by the number of tries so far.

]]>
Keep trying a limited number of times, waiting a growing amount of time between attempts, and then fail by re-throwing the exception. The time between attempts is sleepTime mutliplied by a random number in the range of [0, 2 to the number of retries)

]]>
Set a default policy with some explicit handlers for specific exceptions.

]]>
A retry policy for RemoteException Set a default policy with some explicit handlers for specific exceptions.

]]>
Try once, and fail by re-throwing the exception. This corresponds to having no retry mechanism in place.

]]>
Try once, and fail silently for void methods, or by re-throwing the exception for non-void methods.

]]>
Keep trying forever.

]]>
A collection of useful implementations of {@link RetryPolicy}.

]]>
Determines whether the framework should retry a method for the given exception, and the number of retries that have been made for that operation so far.

@param e The exception that caused the method to fail. @param retries The number of times the method has been retried. @return true if the method should be retried, false if the method should not be retried but shouldn't fail with an exception (only for void methods). @throws Exception The re-thrown exception e indicating that the method failed and should not be retried further.]]>
Specifies a policy for retrying method failures. Implementations of this interface should be immutable.

]]>
Create a proxy for an interface of an implementation class using the same retry policy for each method in the interface.

@param iface the interface that the retry will implement @param implementation the instance whose methods should be retried @param retryPolicy the policy for retirying method call failures @return the retry proxy]]>
Create a proxy for an interface of an implementation class using the a set of retry policies specified by method name. If no retry policy is defined for a method then a default of {@link RetryPolicies#TRY_ONCE_THEN_FAIL} is used.

@param iface the interface that the retry will implement @param implementation the instance whose methods should be retried @param methodNameToPolicyMap a map of method names to retry policies @return the retry proxy]]>
A factory for creating retry proxies.

]]>
A mechanism for selectively retrying methods that throw exceptions under certain circumstances.

Typical usage is

UnreliableImplementation unreliableImpl = new UnreliableImplementation();
UnreliableInterface unreliable = (UnreliableInterface)
  RetryProxy.create(UnreliableInterface.class, unreliableImpl,
    RetryPolicies.retryUpToMaximumCountWithFixedSleep(4, 10, TimeUnit.SECONDS));
unreliable.call();

This will retry any method called on unreliable four times - in this case the call() method - sleeping 10 seconds between each retry. There are a number of {@link org.apache.hadoop.io.retry.RetryPolicies retry policies} available, or you can implement a custom one by implementing {@link org.apache.hadoop.io.retry.RetryPolicy}. It is also possible to specify retry policies on a {@link org.apache.hadoop.io.retry.RetryProxy#create(Class, Object, Map) per-method basis}.

]]>
Prepare the deserializer for reading.

]]>
Deserialize the next object from the underlying input stream. If the object t is non-null then this deserializer may set its internal state to the next object read from the input stream. Otherwise, if the object t is null a new deserialized object will be created.

@return the deserialized object]]>
Close the underlying input stream and clear up any resources.

]]>
Provides a facility for deserializing objects of type from an {@link InputStream}.

Deserializers are stateful, but must not buffer the input since other producers may read from the input between calls to {@link #deserialize(Object)}.

@param ]]>
A {@link RawComparator} that uses a {@link Deserializer} to deserialize the objects to be compared so that the standard {@link Comparator} can be used to compare them.

One may optimize compare-intensive operations by using a custom implementation of {@link RawComparator} that operates directly on byte representations.

@param ]]>
An experimental {@link Serialization} for Java {@link Serializable} classes.

@see JavaSerializationComparator]]>
A {@link RawComparator} that uses a {@link JavaSerialization} {@link Deserializer} to deserialize objects that are then compared via their {@link Comparable} interfaces.

@param @see JavaSerialization]]>
Encapsulates a {@link Serializer}/{@link Deserializer} pair.

@param ]]>
Serializations are found by reading the io.serializations property from conf, which is a comma-delimited list of classnames.

]]>
A factory for {@link Serialization}s.

]]>
Prepare the serializer for writing.

]]>
Serialize t to the underlying output stream.

]]>
Close the underlying output stream and clear up any resources.

]]>
Provides a facility for serializing objects of type to an {@link OutputStream}.

Serializers are stateful, but must not buffer the output since other producers may write to the output between calls to {@link #serialize(Object)}.

@param ]]>
This package provides a mechanism for using different serialization frameworks in Hadoop. The property "io.serializations" defines a list of {@link org.apache.hadoop.io.serializer.Serialization}s that know how to create {@link org.apache.hadoop.io.serializer.Serializer}s and {@link org.apache.hadoop.io.serializer.Deserializer}s.

To add a new serialization framework write an implementation of {@link org.apache.hadoop.io.serializer.Serialization} and add its name to the "io.serializations" property.

]]>
param, to the IPC server running at address, returning the value. Throws exceptions if there are network problems or if the remote code threw an exception. @deprecated Use {@link #call(Writable, InetSocketAddress, Class, UserGroupInformation)} instead]]> param, to the IPC server running at address with the ticket credentials, returning the value. Throws exceptions if there are network problems or if the remote code threw an exception. @deprecated Use {@link #call(Writable, InetSocketAddress, Class, UserGroupInformation)} instead]]> param, to the IPC server running at address which is servicing the protocol protocol, with the ticket credentials, returning the value. Throws exceptions if there are network problems or if the remote code threw an exception.]]> Unwraps any IOException. @param lookupTypes the desired exception class. @return IOException, which is either the lookupClass exception or this.]]> This unwraps any Throwable that has a constructor taking a String as a parameter. Otherwise it returns this. @return Throwable]]> protocol is a Java interface. All parameters and return types must be one of:
  • a primitive type, boolean, byte, char, short, int, long, float, double, or void; or
  • a {@link String}; or
  • a {@link Writable}; or
  • an array of the above types
All methods in the protocol should throw only IOException. No field data of the protocol instance is transmitted.]]>
handlerCount determines the number of handler threads that will be used to process calls.]]>
,name=RpcActivityForPort" Many of the activity metrics are sampled and averaged on an interval which can be specified in the metrics config file.

For the metrics that are sampled and averaged, one must specify a metrics context that does periodic update calls. Most metrics contexts do. The default Null metrics context however does NOT. So if you aren't using any other metrics context then you can turn on the viewing and averaging of sampled metrics by specifying the following two lines in the hadoop-meterics.properties file:

        rpc.class=org.apache.hadoop.metrics.spi.NullContextWithUpdateThread
        rpc.period=10
  

Note that the metrics are collected regardless of the context used. The context with the update thread is used to average the data periodically Impl details: We use a dynamic mbean that gets the list of the metrics from the metrics registry passed as an argument to the constructor]]> This class has a number of metrics variables that are publicly accessible; these variables (objects) have methods to update their values; for example:

{@link #rpcQueueTime}.inc(time)]]> For the statistics that are sampled and averaged, one must specify a metrics context that does periodic update calls. Most do. The default Null metrics context however does NOT. So if you aren't using any other metrics context then you can turn on the viewing and averaging of sampled metrics by specifying the following two lines in the hadoop-meterics.properties file:

        rpc.class=org.apache.hadoop.metrics.spi.NullContextWithUpdateThread
        rpc.period=10
  

Note that the metrics are collected regardless of the context used. The context with the update thread is used to average the data periodically]]> When constructing the instance, if the factory property contextName.class exists, its value is taken to be the name of the class to instantiate. Otherwise, the default is to create an instance of org.apache.hadoop.metrics.spi.NullContext, which is a dummy "no-op" context which will cause all metric data to be discarded. @param contextName the name of the context @return the named MetricsContext]]> When the instance is constructed, this method checks if the file hadoop-metrics.properties exists on the class path. If it exists, it must be in the format defined by java.util.Properties, and all the properties in the file are set as attributes on the newly created ContextFactory instance. @return the singleton ContextFactory instance]]> getFactory() method.]]> startMonitoring() again after calling this. @see #close()]]> recordName. Throws an exception if the metrics implementation is configured with a fixed set of record names and recordName is not in that set. @param recordName the name of the record @throws MetricsException if recordName conflicts with configuration data]]> A record name identifies the kind of data to be reported. For example, a program reporting statistics relating to the disks on a computer might use a record name "diskStats".

A record has zero or more tags. A tag has a name and a value. To continue the example, the "diskStats" record might use a tag named "diskName" to identify a particular disk. Sometimes it is useful to have more than one tag, so there might also be a "diskType" with value "ide" or "scsi" or whatever.

A record also has zero or more metrics. These are the named values that are to be reported to the metrics system. In the "diskStats" example, possible metric names would be "diskPercentFull", "diskPercentBusy", "kbReadPerSecond", etc.

The general procedure for using a MetricsRecord is to fill in its tag and metric values, and then call update() to pass the record to the client library. Metric data is not immediately sent to the metrics system each time that update() is called. An internal table is maintained, identified by the record name. This table has columns corresponding to the tag and the metric names, and rows corresponding to each unique set of tag values. An update either modifies an existing row in the table, or adds a new row with a set of tag values that are different from all the other rows. Note that if there are no tags, then there can be at most one row in the table.

Once a row is added to the table, its data will be sent to the metrics system on every timer period, whether or not it has been updated since the previous timer period. If this is inappropriate, for example if metrics were being reported by some transient object in an application, the remove() method can be used to remove the row and thus stop the data from being sent.

Note that the update() method is atomic. This means that it is safe for different threads to be updating the same metric. More precisely, it is OK for different threads to call update() on MetricsRecord instances with the same set of tag names and tag values. Different threads should not use the same MetricsRecord instance at the same time.]]> MetricsContext.registerUpdater().]]> The API is abstract so that it can be implemented on top of a variety of metrics client libraries. The choice of client library is a configuration option, and different modules within the same application can use different metrics implementation libraries.

Sub-packages:

org.apache.hadoop.metrics.spi
The abstract Server Provider Interface package. Those wishing to integrate the metrics API with a particular metrics client library should extend this package.
org.apache.hadoop.metrics.file
An implementation package which writes the metric data to a file, or sends it to the standard output stream.
org.apache.hadoop.metrics.ganglia
An implementation package which sends metric data to Ganglia.

Introduction to the Metrics API

Here is a simple example of how to use this package to report a single metric value:
    private ContextFactory contextFactory = ContextFactory.getFactory();
    
    void reportMyMetric(float myMetric) {
        MetricsContext myContext = contextFactory.getContext("myContext");
        MetricsRecord myRecord = myContext.getRecord("myRecord");
        myRecord.setMetric("myMetric", myMetric);
        myRecord.update();
    }
In this example there are three names:
myContext
The context name will typically identify either the application, or else a module within an application or library.
myRecord
The record name generally identifies some entity for which a set of metrics are to be reported. For example, you could have a record named "cacheStats" for reporting a number of statistics relating to the usage of some cache in your application.
myMetric
This identifies a particular metric. For example, you might have metrics named "cache_hits" and "cache_misses".

Tags

In some cases it is useful to have multiple records with the same name. For example, suppose that you want to report statistics about each disk on a computer. In this case, the record name would be something like "diskStats", but you also need to identify the disk which is done by adding a tag to the record. The code could look something like this:
    private MetricsRecord diskStats =
            contextFactory.getContext("myContext").getRecord("diskStats");
            
    void reportDiskMetrics(String diskName, float diskBusy, float diskUsed) {
        diskStats.setTag("diskName", diskName);
        diskStats.setMetric("diskBusy", diskBusy);
        diskStats.setMetric("diskUsed", diskUsed);
        diskStats.update();
    }

Buffering and Callbacks

Data is not sent immediately to the metrics system when MetricsRecord.update() is called. Instead it is stored in an internal table, and the contents of the table are sent periodically. This can be important for two reasons:
  1. It means that a programmer is free to put calls to this API in an inner loop, since updates can be very frequent without slowing down the application significantly.
  2. Some implementations can gain efficiency by combining many metrics into a single UDP message.
The API provides a timer-based callback via the registerUpdater() method. The benefit of this versus using java.util.Timer is that the callbacks will be done immediately before sending the data, making the data as current as possible.

Configuration

It is possible to programmatically examine and modify configuration data before creating a context, like this:
    ContextFactory factory = ContextFactory.getFactory();
    ... examine and/or modify factory attributes ...
    MetricsContext context = factory.getContext("myContext");
The factory attributes can be examined and modified using the following ContextFactorymethods:

ContextFactory.getFactory() initializes the factory attributes by reading the properties file hadoop-metrics.properties if it exists on the class path.

A factory attribute named:

contextName.class
should have as its value the fully qualified name of the class to be instantiated by a call of the CodeFactory method getContext(contextName). If this factory attribute is not specified, the default is to instantiate org.apache.hadoop.metrics.file.FileContext.

Other factory attributes are specific to a particular implementation of this API and are documented elsewhere. For example, configuration attributes for the file and Ganglia implementations can be found in the javadoc for their respective packages.]]> fileName attribute, if specified. Otherwise the data will be written to standard output.]]> This class is configured by setting ContextFactory attributes which in turn are usually configured through a properties file. All the attributes are prefixed by the contextName. For example, the properties file might contain:

 myContextName.fileName=/tmp/metrics.log
 myContextName.period=5
 
]]> These are the implementation specific factory attributes (See ContextFactory.getFactory()):
contextName.fileName
The path of the file to which metrics in context contextName are to be appended. If this attribute is not specified, the metrics are written to standard output by default.
contextName.period
The period in seconds on which the metric data is written to the file.
]]>
Implementation of the metrics package that sends metric data to Ganglia. Programmers should not normally need to use this package directly. Instead they should use org.hadoop.metrics.

These are the implementation specific factory attributes (See ContextFactory.getFactory()):

contextName.servers
Space and/or comma separated sequence of servers to which UDP messages should be sent.
contextName.period
The period in seconds on which the metric data is sent to the server(s).
contextName.units.recordName.metricName
The units for the specified metric in the specified record.
contextName.slope.recordName.metricName
The slope for the specified metric in the specified record.
contextName.tmax.recordName.metricName
The tmax for the specified metric in the specified record.
contextName.dmax.recordName.metricName
The dmax for the specified metric in the specified record.
]]>
contextName.tableName. The returned map consists of those attributes with the contextName and tableName stripped off.]]> recordName. Throws an exception if the metrics implementation is configured with a fixed set of record names and recordName is not in that set. @param recordName the name of the record @throws MetricsException if recordName conflicts with configuration data]]> This class implements the internal table of metric data, and the timer on which data is to be sent to the metrics system. Subclasses must override the abstract emitRecord method in order to transmit the data.

]]> update and remove().]]> hostname or hostname:port. If the specs string is null, defaults to localhost:defaultPort. @return a list of InetSocketAddress objects.]]> org.apache.hadoop.metrics.file and org.apache.hadoop.metrics.ganglia.

Plugging in an implementation involves writing a concrete subclass of AbstractMetricsContext. The subclass should get its configuration information using the getAttribute(attributeName) method.]]> ,name=" Where the and are the supplied parameters @param serviceName @param nameName @param theMbean - the MBean to register @return the named used to register the MBean]]> hadoop.rpc.socket.factory.class.<ClassName>. When no such parameter exists then fall back on the default socket factory as configured by hadoop.rpc.socket.factory.class.default. If this default socket factory is not configured, then fall back on the JVM default socket factory. @param conf the configuration @param clazz the class (usually a {@link VersionedProtocol}) @return a socket factory]]> hadoop.rpc.socket.factory.default @param conf the configuration @return the default socket factory as specified in the configuration or the JVM default socket factory if the configuration does not contain a default socket factory property.]]> : ://:/]]> : ://:/]]>
From documentation for {@link #getInputStream(Socket, long)}:
Returns InputStream for the socket. If the socket has an associated SocketChannel then it returns a {@link SocketInputStream} with the given timeout. If the socket does not have a channel, {@link Socket#getInputStream()} is returned. In the later case, the timeout argument is ignored and the timeout set with {@link Socket#setSoTimeout(int)} applies for reads.

Any socket created using socket factories returned by {@link #NetUtils}, must use this interface instead of {@link Socket#getInputStream()}. @see #getInputStream(Socket, long) @param socket @return InputStream for reading from the socket. @throws IOException]]>

Any socket created using socket factories returned by {@link #NetUtils}, must use this interface instead of {@link Socket#getInputStream()}. @see Socket#getChannel() @param socket @param timeout timeout in milliseconds. This may not always apply. zero for waiting as long as necessary. @return InputStream for reading from the socket. @throws IOException]]>

From documentation for {@link #getOutputStream(Socket, long)} :
Returns OutputStream for the socket. If the socket has an associated SocketChannel then it returns a {@link SocketOutputStream} with the given timeout. If the socket does not have a channel, {@link Socket#getOutputStream()} is returned. In the later case, the timeout argument is ignored and the write will wait until data is available.

Any socket created using socket factories returned by {@link #NetUtils}, must use this interface instead of {@link Socket#getOutputStream()}. @see #getOutputStream(Socket, long) @param socket @return OutputStream for writing to the socket. @throws IOException]]>

Any socket created using socket factories returned by {@link #NetUtils}, must use this interface instead of {@link Socket#getOutputStream()}. @see Socket#getChannel() @param socket @param timeout timeout in milliseconds. This may not always apply. zero for waiting as long as necessary. @return OutputStream for writing to the socket. @throws IOException]]>
socket.connect(endpoint, timeout). If socket.getChannel() returns a non-null channel, connect is implemented using Hadoop's selectors. This is done mainly to avoid Sun's connect implementation from creating thread-local selectors, since Hadoop does not have control on when these are closed and could end up taking all the available file descriptors. @see java.net.Socket#connect(java.net.SocketAddress, int) @param socket @param endpoint @param timeout - timeout in milliseconds]]>
node @param node a node @return true if node is already in the tree; false otherwise]]> scope if scope starts with ~, choose one from the all nodes except for the ones in scope; otherwise, choose one from scope @param scope range of nodes from which a node will be choosen @return the choosen node]]> scope but not in excludedNodes if scope starts with ~, return the number of nodes that are not in scope and excludedNodes; @param scope a path string that may start with ~ @param excludedNodes a list of nodes @return number of available nodes]]> reader It linearly scans the array, if a local node is found, swap it with the first element of the array. If a local rack node is found, swap it with the first element following the local node. If neither local node or local rack node is found, put a random replica location at postion 0. It leaves the rest nodes untouched.]]>
Create a new input stream with the given timeout. If the timeout is zero, it will be treated as infinite timeout. The socket's channel will be configured to be non-blocking. @see SocketInputStream#SocketInputStream(ReadableByteChannel, long) @param socket should have a channel associated with it. @param timeout timeout timeout in milliseconds. must not be negative. @throws IOException]]>

Create a new input stream with the given timeout. If the timeout is zero, it will be treated as infinite timeout. The socket's channel will be configured to be non-blocking. @see SocketInputStream#SocketInputStream(ReadableByteChannel, long) @param socket should have a channel associated with it. @throws IOException]]>

Create a new ouput stream with the given timeout. If the timeout is zero, it will be treated as infinite timeout. The socket's channel will be configured to be non-blocking. @see SocketOutputStream#SocketOutputStream(WritableByteChannel, long) @param socket should have a channel associated with it. @param timeout timeout timeout in milliseconds. must not be negative. @throws IOException]]>
= getCount(). @param newCapacity The new capacity in bytes.]]> Index idx = startVector(...); while (!idx.done()) { .... // read element of a vector idx.incr(); } ]]> Introduction Software systems of any significant complexity require mechanisms for data interchange with the outside world. These interchanges typically involve the marshaling and unmarshaling of logical units of data to and from data streams (files, network connections, memory buffers etc.). Applications usually have some code for serializing and deserializing the data types that they manipulate embedded in them. The work of serialization has several features that make automatic code generation for it worthwhile. Given a particular output encoding (binary, XML, etc.), serialization of primitive types and simple compositions of primitives (structs, vectors etc.) is a very mechanical task. Manually written serialization code can be susceptible to bugs especially when records have a large number of fields or a record definition changes between software versions. Lastly, it can be very useful for applications written in different programming languages to be able to share and interchange data. This can be made a lot easier by describing the data records manipulated by these applications in a language agnostic manner and using the descriptions to derive implementations of serialization in multiple target languages. This document describes Hadoop Record I/O, a mechanism that is aimed at

  • enabling the specification of simple serializable data types (records)
  • enabling the generation of code in multiple target languages for marshaling and unmarshaling such types
  • providing target language specific support that will enable application programmers to incorporate generated code into their applications
The goals of Hadoop Record I/O are similar to those of mechanisms such as XDR, ASN.1, PADS and ICE. While these systems all include a DDL that enables the specification of most record types, they differ widely in what else they focus on. The focus in Hadoop Record I/O is on data marshaling and multi-lingual support. We take a translator-based approach to serialization. Hadoop users have to describe their data in a simple data description language. The Hadoop DDL translator rcc generates code that users can invoke in order to read/write their data from/to simple stream abstractions. Next we list explicitly some of the goals and non-goals of Hadoop Record I/O.

Goals

  • Support for commonly used primitive types. Hadoop should include as primitives commonly used builtin types from programming languages we intend to support.
  • Support for common data compositions (including recursive compositions). Hadoop should support widely used composite types such as structs and vectors.
  • Code generation in multiple target languages. Hadoop should be capable of generating serialization code in multiple target languages and should be easily extensible to new target languages. The initial target languages are C++ and Java.
  • Support for generated target languages. Hadooop should include support in the form of headers, libraries, packages for supported target languages that enable easy inclusion and use of generated code in applications.
  • Support for multiple output encodings. Candidates include packed binary, comma-separated text, XML etc.
  • Support for specifying record types in a backwards/forwards compatible manner. This will probably be in the form of support for optional fields in records. This version of the document does not include a description of the planned mechanism, we intend to include it in the next iteration.

Non-Goals

  • Serializing existing arbitrary C++ classes.
  • Serializing complex data structures such as trees, linked lists etc.
  • Built-in indexing schemes, compression, or check-sums.
  • Dynamic construction of objects from an XML schema.
The remainder of this document describes the features of Hadoop record I/O in more detail. Section 2 describes the data types supported by the system. Section 3 lays out the DDL syntax with some examples of simple records. Section 4 describes the process of code generation with rcc. Section 5 describes target language mappings and support for Hadoop types. We include a fairly complete description of C++ mappings with intent to include Java and others in upcoming iterations of this document. The last section talks about supported output encodings.

Data Types and Streams

This section describes the primitive and composite types supported by Hadoop. We aim to support a set of types that can be used to simply and efficiently express a wide range of record types in different programming languages.

Primitive Types

For the most part, the primitive types of Hadoop map directly to primitive types in high level programming languages. Special cases are the ustring (a Unicode string) and buffer types, which we believe find wide use and which are usually implemented in library code and not available as language built-ins. Hadoop also supplies these via library code when a target language built-in is not present and there is no widely adopted "standard" implementation. The complete list of primitive types is:
  • byte: An 8-bit unsigned integer.
  • boolean: A boolean value.
  • int: A 32-bit signed integer.
  • long: A 64-bit signed integer.
  • float: A single precision floating point number as described by IEEE-754.
  • double: A double precision floating point number as described by IEEE-754.
  • ustring: A string consisting of Unicode characters.
  • buffer: An arbitrary sequence of bytes.

Composite Types

Hadoop supports a small set of composite types that enable the description of simple aggregate types and containers. A composite type is serialized by sequentially serializing it constituent elements. The supported composite types are:
  • record: An aggregate type like a C-struct. This is a list of typed fields that are together considered a single unit of data. A record is serialized by sequentially serializing its constituent fields. In addition to serialization a record has comparison operations (equality and less-than) implemented for it, these are defined as memberwise comparisons.
  • vector: A sequence of entries of the same data type, primitive or composite.
  • map: An associative container mapping instances of a key type to instances of a value type. The key and value types may themselves be primitive or composite types.

Streams

Hadoop generates code for serializing and deserializing record types to abstract streams. For each target language Hadoop defines very simple input and output stream interfaces. Application writers can usually develop concrete implementations of these by putting a one method wrapper around an existing stream implementation.

DDL Syntax and Examples

We now describe the syntax of the Hadoop data description language. This is followed by a few examples of DDL usage.

Hadoop DDL Syntax


recfile = *include module *record
include = "include" path
path = (relative-path / absolute-path)
module = "module" module-name
module-name = name *("." name)
record := "class" name "{" 1*(field) "}"
field := type name ";"
name :=  ALPHA (ALPHA / DIGIT / "_" )*
type := (ptype / ctype)
ptype := ("byte" / "boolean" / "int" |
          "long" / "float" / "double"
          "ustring" / "buffer")
ctype := (("vector" "<" type ">") /
          ("map" "<" type "," type ">" ) ) / name)
A DDL file describes one or more record types. It begins with zero or more include declarations, a single mandatory module declaration followed by zero or more class declarations. The semantics of each of these declarations are described below:
  • include: An include declaration specifies a DDL file to be referenced when generating code for types in the current DDL file. Record types in the current compilation unit may refer to types in all included files. File inclusion is recursive. An include does not trigger code generation for the referenced file.
  • module: Every Hadoop DDL file must have a single module declaration that follows the list of includes and precedes all record declarations. A module declaration identifies a scope within which the names of all types in the current file are visible. Module names are mapped to C++ namespaces, Java packages etc. in generated code.
  • class: Records types are specified through class declarations. A class declaration is like a Java class declaration. It specifies a named record type and a list of fields that constitute records of the type. Usage is illustrated in the following examples.

Examples

  • A simple DDL file links.jr with just one record declaration.
    
    module links {
        class Link {
            ustring URL;
            boolean isRelative;
            ustring anchorText;
        };
    }
    
  • A DDL file outlinks.jr which includes another
    
    include "links.jr"
    
    module outlinks {
        class OutLinks {
            ustring baseURL;
            vector outLinks;
        };
    }
    

Code Generation

The Hadoop translator is written in Java. Invocation is done by executing a wrapper shell script named named rcc. It takes a list of record description files as a mandatory argument and an optional language argument (the default is Java) --language or -l. Thus a typical invocation would look like:

$ rcc -l C++  ...

Target Language Mappings and Support

For all target languages, the unit of code generation is a record type. For each record type, Hadoop generates code for serialization and deserialization, record comparison and access to record members.

C++

Support for including Hadoop generated C++ code in applications comes in the form of a header file recordio.hh which needs to be included in source that uses Hadoop types and a library librecordio.a which applications need to be linked with. The header declares the Hadoop C++ namespace which defines appropriate types for the various primitives, the basic interfaces for records and streams and enumerates the supported serialization encodings. Declarations of these interfaces and a description of their semantics follow:

namespace hadoop {

  enum RecFormat { kBinary, kXML, kCSV };

  class InStream {
  public:
    virtual ssize_t read(void *buf, size_t n) = 0;
  };

  class OutStream {
  public:
    virtual ssize_t write(const void *buf, size_t n) = 0;
  };

  class IOError : public runtime_error {
  public:
    explicit IOError(const std::string& msg);
  };

  class IArchive;
  class OArchive;

  class RecordReader {
  public:
    RecordReader(InStream& in, RecFormat fmt);
    virtual ~RecordReader(void);

    virtual void read(Record& rec);
  };

  class RecordWriter {
  public:
    RecordWriter(OutStream& out, RecFormat fmt);
    virtual ~RecordWriter(void);

    virtual void write(Record& rec);
  };


  class Record {
  public:
    virtual std::string type(void) const = 0;
    virtual std::string signature(void) const = 0;
  protected:
    virtual bool validate(void) const = 0;

    virtual void
    serialize(OArchive& oa, const std::string& tag) const = 0;

    virtual void
    deserialize(IArchive& ia, const std::string& tag) = 0;
  };
}
  • RecFormat: An enumeration of the serialization encodings supported by this implementation of Hadoop.
  • InStream: A simple abstraction for an input stream. This has a single public read method that reads n bytes from the stream into the buffer buf. Has the same semantics as a blocking read system call. Returns the number of bytes read or -1 if an error occurs.
  • OutStream: A simple abstraction for an output stream. This has a single write method that writes n bytes to the stream from the buffer buf. Has the same semantics as a blocking write system call. Returns the number of bytes written or -1 if an error occurs.
  • RecordReader: A RecordReader reads records one at a time from an underlying stream in a specified record format. The reader is instantiated with a stream and a serialization format. It has a read method that takes an instance of a record and deserializes the record from the stream.
  • RecordWriter: A RecordWriter writes records one at a time to an underlying stream in a specified record format. The writer is instantiated with a stream and a serialization format. It has a write method that takes an instance of a record and serializes the record to the stream.
  • Record: The base class for all generated record types. This has two public methods type and signature that return the typename and the type signature of the record.
Two files are generated for each record file (note: not for each record). If a record file is named "name.jr", the generated files are "name.jr.cc" and "name.jr.hh" containing serialization implementations and record type declarations respectively. For each record in the DDL file, the generated header file will contain a class definition corresponding to the record type, method definitions for the generated type will be present in the '.cc' file. The generated class will inherit from the abstract class hadoop::Record. The DDL files module declaration determines the namespace the record belongs to. Each '.' delimited token in the module declaration results in the creation of a namespace. For instance, the declaration module docs.links results in the creation of a docs namespace and a nested docs::links namespace. In the preceding examples, the Link class is placed in the links namespace. The header file corresponding to the links.jr file will contain:

namespace links {
  class Link : public hadoop::Record {
    // ....
  };
};
Each field within the record will cause the generation of a private member declaration of the appropriate type in the class declaration, and one or more acccessor methods. The generated class will implement the serialize and deserialize methods defined in hadoop::Record+. It will also implement the inspection methods type and signature from hadoop::Record. A default constructor and virtual destructor will also be generated. Serialization code will read/write records into streams that implement the hadoop::InStream and the hadoop::OutStream interfaces. For each member of a record an accessor method is generated that returns either the member or a reference to the member. For members that are returned by value, a setter method is also generated. This is true for primitive data members of the types byte, int, long, boolean, float and double. For example, for a int field called MyField the folowing code is generated.

...
private:
  int32_t mMyField;
  ...
public:
  int32_t getMyField(void) const {
    return mMyField;
  };

  void setMyField(int32_t m) {
    mMyField = m;
  };
  ...
For a ustring or buffer or composite field. The generated code only contains accessors that return a reference to the field. A const and a non-const accessor are generated. For example:

...
private:
  std::string mMyBuf;
  ...
public:

  std::string& getMyBuf() {
    return mMyBuf;
  };

  const std::string& getMyBuf() const {
    return mMyBuf;
  };
  ...

Examples

Suppose the inclrec.jr file contains:

module inclrec {
    class RI {
        int      I32;
        double   D;
        ustring  S;
    };
}
and the testrec.jr file contains:

include "inclrec.jr"
module testrec {
    class R {
        vector VF;
        RI            Rec;
        buffer        Buf;
    };
}
Then the invocation of rcc such as:

$ rcc -l c++ inclrec.jr testrec.jr
will result in generation of four files: inclrec.jr.{cc,hh} and testrec.jr.{cc,hh}. The inclrec.jr.hh will contain:

#ifndef _INCLREC_JR_HH_
#define _INCLREC_JR_HH_

#include "recordio.hh"

namespace inclrec {
  
  class RI : public hadoop::Record {

  private:

    int32_t      I32;
    double       D;
    std::string  S;

  public:

    RI(void);
    virtual ~RI(void);

    virtual bool operator==(const RI& peer) const;
    virtual bool operator<(const RI& peer) const;

    virtual int32_t getI32(void) const { return I32; }
    virtual void setI32(int32_t v) { I32 = v; }

    virtual double getD(void) const { return D; }
    virtual void setD(double v) { D = v; }

    virtual std::string& getS(void) const { return S; }
    virtual const std::string& getS(void) const { return S; }

    virtual std::string type(void) const;
    virtual std::string signature(void) const;

  protected:

    virtual void serialize(hadoop::OArchive& a) const;
    virtual void deserialize(hadoop::IArchive& a);
  };
} // end namespace inclrec

#endif /* _INCLREC_JR_HH_ */

The testrec.jr.hh file will contain:


#ifndef _TESTREC_JR_HH_
#define _TESTREC_JR_HH_

#include "inclrec.jr.hh"

namespace testrec {
  class R : public hadoop::Record {

  private:

    std::vector VF;
    inclrec::RI        Rec;
    std::string        Buf;

  public:

    R(void);
    virtual ~R(void);

    virtual bool operator==(const R& peer) const;
    virtual bool operator<(const R& peer) const;

    virtual std::vector& getVF(void) const;
    virtual const std::vector& getVF(void) const;

    virtual std::string& getBuf(void) const ;
    virtual const std::string& getBuf(void) const;

    virtual inclrec::RI& getRec(void) const;
    virtual const inclrec::RI& getRec(void) const;
    
    virtual bool serialize(hadoop::OutArchive& a) const;
    virtual bool deserialize(hadoop::InArchive& a);
    
    virtual std::string type(void) const;
    virtual std::string signature(void) const;
  };
}; // end namespace testrec
#endif /* _TESTREC_JR_HH_ */

Java

Code generation for Java is similar to that for C++. A Java class is generated for each record type with private members corresponding to the fields. Getters and setters for fields are also generated. Some differences arise in the way comparison is expressed and in the mapping of modules to packages and classes to files. For equality testing, an equals method is generated for each record type. As per Java requirements a hashCode method is also generated. For comparison a compareTo method is generated for each record type. This has the semantics as defined by the Java Comparable interface, that is, the method returns a negative integer, zero, or a positive integer as the invoked object is less than, equal to, or greater than the comparison parameter. A .java file is generated per record type as opposed to per DDL file as in C++. The module declaration translates to a Java package declaration. The module name maps to an identical Java package name. In addition to this mapping, the DDL compiler creates the appropriate directory hierarchy for the package and places the generated .java files in the correct directories.

Mapping Summary


DDL Type        C++ Type            Java Type 

boolean         bool                boolean
byte            int8_t              byte
int             int32_t             int
long            int64_t             long
float           float               float
double          double              double
ustring         std::string         java.lang.String
buffer          std::string         org.apache.hadoop.record.Buffer
class type      class type          class type
vector    std::vector   java.util.ArrayList
map  std::map java.util.TreeMap

Data encodings

This section describes the format of the data encodings supported by Hadoop. Currently, three data encodings are supported, namely binary, CSV and XML.

Binary Serialization Format

The binary data encoding format is fairly dense. Serialization of composite types is simply defined as a concatenation of serializations of the constituent elements (lengths are included in vectors and maps). Composite types are serialized as follows:
  • class: Sequence of serialized members.
  • vector: The number of elements serialized as an int. Followed by a sequence of serialized elements.
  • map: The number of key value pairs serialized as an int. Followed by a sequence of serialized (key,value) pairs.
Serialization of primitives is more interesting, with a zero compression optimization for integral types and normalization to UTF-8 for strings. Primitive types are serialized as follows:
  • byte: Represented by 1 byte, as is.
  • boolean: Represented by 1-byte (0 or 1)
  • int/long: Integers and longs are serialized zero compressed. Represented as 1-byte if -120 <= value < 128. Otherwise, serialized as a sequence of 2-5 bytes for ints, 2-9 bytes for longs. The first byte represents the number of trailing bytes, N, as the negative number (-120-N). For example, the number 1024 (0x400) is represented by the byte sequence 'x86 x04 x00'. This doesn't help much for 4-byte integers but does a reasonably good job with longs without bit twiddling.
  • float/double: Serialized in IEEE 754 single and double precision format in network byte order. This is the format used by Java.
  • ustring: Serialized as 4-byte zero compressed length followed by data encoded as UTF-8. Strings are normalized to UTF-8 regardless of native language representation.
  • buffer: Serialized as a 4-byte zero compressed length followed by the raw bytes in the buffer.

CSV Serialization Format

The CSV serialization format has a lot more structure than the "standard" Excel CSV format, but we believe the additional structure is useful because
  • it makes parsing a lot easier without detracting too much from legibility
  • the delimiters around composites make it obvious when one is reading a sequence of Hadoop records
Serialization formats for the various types are detailed in the grammar that follows. The notable feature of the formats is the use of delimiters for indicating the certain field types.
  • A string field begins with a single quote (').
  • A buffer field begins with a sharp (#).
  • A class, vector or map begins with 's{', 'v{' or 'm{' respectively and ends with '}'.
The CSV format can be described by the following grammar:

record = primitive / struct / vector / map
primitive = boolean / int / long / float / double / ustring / buffer

boolean = "T" / "F"
int = ["-"] 1*DIGIT
long = ";" ["-"] 1*DIGIT
float = ["-"] 1*DIGIT "." 1*DIGIT ["E" / "e" ["-"] 1*DIGIT]
double = ";" ["-"] 1*DIGIT "." 1*DIGIT ["E" / "e" ["-"] 1*DIGIT]

ustring = "'" *(UTF8 char except NULL, LF, % and , / "%00" / "%0a" / "%25" / "%2c" )

buffer = "#" *(BYTE except NULL, LF, % and , / "%00" / "%0a" / "%25" / "%2c" )

struct = "s{" record *("," record) "}"
vector = "v{" [record *("," record)] "}"
map = "m{" [*(record "," record)] "}"

XML Serialization Format

The XML serialization format is the same used by Apache XML-RPC (http://ws.apache.org/xmlrpc/types.html). This is an extension of the original XML-RPC format and adds some additional data types. All record I/O types are not directly expressible in this format, and access to a DDL is required in order to convert these to valid types. All types primitive or composite are represented by <value> elements. The particular XML-RPC type is indicated by a nested element in the <value> element. The encoding for records is always UTF-8. Primitive types are serialized as follows:
  • byte: XML tag <ex:i1>. Values: 1-byte unsigned integers represented in US-ASCII
  • boolean: XML tag <boolean>. Values: "0" or "1"
  • int: XML tags <i4> or <int>. Values: 4-byte signed integers represented in US-ASCII.
  • long: XML tag <ex:i8>. Values: 8-byte signed integers represented in US-ASCII.
  • float: XML tag <ex:float>. Values: Single precision floating point numbers represented in US-ASCII.
  • double: XML tag <double>. Values: Double precision floating point numbers represented in US-ASCII.
  • ustring: XML tag <;string>. Values: String values represented as UTF-8. XML does not permit all Unicode characters in literal data. In particular, NULLs and control chars are not allowed. Additionally, XML processors are required to replace carriage returns with line feeds and to replace CRLF sequences with line feeds. Programming languages that we work with do not impose these restrictions on string types. To work around these restrictions, disallowed characters and CRs are percent escaped in strings. The '%' character is also percent escaped.
  • buffer: XML tag <string&>. Values: Arbitrary binary data. Represented as hexBinary, each byte is replaced by its 2-byte hexadecimal representation.
Composite types are serialized as follows:
  • class: XML tag <struct>. A struct is a sequence of <member> elements. Each <member> element has a <name> element and a <value> element. The <name> is a string that must match /[a-zA-Z][a-zA-Z0-9_]*/. The value of the member is represented by a <value> element.
  • vector: XML tag <array<. An <array> contains a single <data> element. The <data> element is a sequence of <value> elements each of which represents an element of the vector.
  • map: XML tag <array>. Same as vector.
For example:

class {
  int           MY_INT;            // value 5
  vector MY_VEC;            // values 0.1, -0.89, 2.45e4
  buffer        MY_BUF;            // value '\00\n\tabc%'
}
is serialized as

<value>
  <struct>
    <member>
      <name>MY_INT</name>
      <value><i4>5</i4></value>
    </member>
    <member>
      <name>MY_VEC</name>
      <value>
        <array>
          <data>
            <value><ex:float>0.1</ex:float></value>
            <value><ex:float>-0.89</ex:float></value>
            <value><ex:float>2.45e4</ex:float></value>
          </data>
        </array>
      </value>
    </member>
    <member>
      <name>MY_BUF</name>
      <value><string>%00\n\tabc%25</string></value>
    </member>
  </struct>
</value> 
]]>
This task takes the given record definition files and compiles them into java or c++ files. It is then up to the user to compile the generated files.

The task requires the file or the nested fileset element to be specified. Optional attributes are language (set the output language, default is "java"), destdir (name of the destination directory for generated java/c++ code, default is ".") and failonerror (specifies error handling behavior. default is true).

Usage

 <recordcc
       destdir="${basedir}/gensrc"
       language="java">
   <fileset include="**\/*.jr" />
 </recordcc>
 
]]>
]]> (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause). @param cause the cause (which is saved for later retrieval by the {@link #getCause()} method). (A null value is permitted, and indicates that the cause is nonexistent or unknown.)]]> Group with the given groupname. @param group group name]]> ugi. @param ugi user @return the {@link Subject} for the user identified by ugi]]> ugi as a comma separated string in conf as a property attr The String starts with the user name followed by the default group names, and other group names. @param conf configuration @param attr property name @param ugi a UnixUserGroupInformation]]> conf The object is expected to store with the property name attr as a comma separated string that starts with the user name followed by group names. If the property name is not defined, return null. It's assumed that there is only one UGI per user. If this user already has a UGI in the ugi map, return the ugi in the map. Otherwise, construct a UGI from the configuration, store it in the ugi map and return it. @param conf configuration @param attr property name @return a UnixUGI @throws LoginException if the stored string is ill-formatted.]]> User with the given username. @param user user name]]> (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause). @param cause the cause (which is saved for later retrieval by the {@link #getCause()} method). (A null value is permitted, and indicates that the cause is nonexistent or unknown.)]]> does not provide the stack trace for security purposes.]]> service as related to Service Level Authorization for Hadoop. Each service defines it's configuration key and also the necessary {@link Permission} required to access the service.]]> in]]> out.]]> reset is true, then resets the checksum. @return number of bytes written. Will be equal to getChecksumSize();]]> reset is true, then resets the checksum. @return number of bytes written. Will be equal to getChecksumSize();]]> GenericOptionsParser to parse only the generic Hadoop arguments. The array of string arguments other than the generic arguments can be obtained by {@link #getRemainingArgs()}. @param conf the Configuration to modify. @param args command-line arguments.]]> GenericOptionsParser to parse given options as well as generic Hadoop options. The resulting CommandLine object can be obtained by {@link #getCommandLine()}. @param conf the configuration to modify @param options options built by the caller @param args User-specified arguments]]> Strings containing the un-parsed arguments or empty array if commandLine was not defined.]]> CommandLine object to process the parsed arguments. Note: If the object is created with {@link #GenericOptionsParser(Configuration, String[])}, then returned object will only contain parsed generic options. @return CommandLine representing list of arguments parsed against Options descriptor.]]> GenericOptionsParser is a utility to parse command line arguments generic to the Hadoop framework. GenericOptionsParser recognizes several standarad command line arguments, enabling applications to easily specify a namenode, a jobtracker, additional configuration resources etc.

Generic Options

The supported generic options are:

     -conf <configuration file>     specify a configuration file
     -D <property=value>            use value for given property
     -fs <local|namenode:port>      specify a namenode
     -jt <local|jobtracker:port>    specify a job tracker
     -files <comma separated list of files>    specify comma separated
                            files to be copied to the map reduce cluster
     -libjars <comma separated list of jars>   specify comma separated
                            jar files to include in the classpath.
     -archives <comma separated list of archives>    specify comma
             separated archives to be unarchived on the compute machines.

 

The general command line syntax is:

 bin/hadoop command [genericOptions] [commandOptions]
 

Generic command line arguments might modify Configuration objects, given to constructors.

The functionality is implemented using Commons CLI.

Examples:

 $ bin/hadoop dfs -fs darwin:8020 -ls /data
 list /data directory in dfs with namenode darwin:8020
 
 $ bin/hadoop dfs -D fs.default.name=darwin:8020 -ls /data
 list /data directory in dfs with namenode darwin:8020
     
 $ bin/hadoop dfs -conf hadoop-site.xml -ls /data
 list /data directory in dfs with conf specified in hadoop-site.xml
     
 $ bin/hadoop job -D mapred.job.tracker=darwin:50020 -submit job.xml
 submit a job to job tracker darwin:50020
     
 $ bin/hadoop job -jt darwin:50020 -submit job.xml
 submit a job to job tracker darwin:50020
     
 $ bin/hadoop job -jt local -submit job.xml
 submit a job to local runner
 
 $ bin/hadoop jar -libjars testlib.jar 
 -archives test.tgz -files file.txt inputjar args
 job submission with libjars, files and archives
 

@see Tool @see ToolRunner]]>
Class<T>) of the argument of type T. @param The type of the argument @param t the object to get it class @return Class<T>]]> List<T> to a an array of T[]. @param c the Class object of the items in the list @param list the list to convert]]> List<T> to a an array of T[]. @param list the list to convert @throws ArrayIndexOutOfBoundsException if the list is empty. Use {@link #toArray(Class, List)} if the list may be empty.]]> io.file.buffer.size specified in the given Configuration. @param in input stream @param conf configuration @throws IOException]]> true if native-hadoop is loaded, else false]]> true if native hadoop libraries, if present, can be used for this job; false otherwise.]]> { pq.top().change(); pq.adjustTop(); } instead of
  { o = pq.pop(); o.change(); pq.push(o); }
 
]]>
Clients and/or applications can use the provided Progressable to explicitly report progress to the Hadoop framework. This is especially important for operations which take an insignificant amount of time since, in-lieu of the reported progress, the framework has to assume that an error has occured and time-out the operation.

]]>
Class is to be obtained @return the correctly typed Class of the given object.]]> Hadoop Pipes or Hadoop Streaming. It also checks to ensure that we are running on a *nix platform else (e.g. in Cygwin/Windows) it returns null. @param conf configuration @return a String[] with the ulimit command arguments or null if we are running on a non *nix platform or if the limit is unspecified.]]> Shell interface. @param cmd shell command to execute. @return the output of the executed command.]]> Shell interface. @param env the map of environment key=value @param cmd shell command to execute. @return the output of the executed command.]]> Shell can be used to run unix commands like du or df. It also offers facilities to gate commands by time-intervals.]]> ShellCommandExecutorshould be used in cases where the output of the command needs no explicit parsing and where the command, working directory and the environment remains unchanged. The output of the command is stored as-is and is expected to be small.]]> ArrayList of string values]]> charToEscape in the string with the escape char escapeChar @param str string @param escapeChar escape char @param charToEscape the char to be escaped @return an escaped string]]> charToEscape in the string with the escape char escapeChar @param str string @param escapeChar escape char @param charToEscape the escaped char @return an unescaped string]]> Tool, is the standard for any Map-Reduce tool/application. The tool/application should delegate the handling of standard command-line options to {@link ToolRunner#run(Tool, String[])} and only handle its custom arguments.

Here is how a typical Tool is implemented:

     public class MyApp extends Configured implements Tool {
     
       public int run(String[] args) throws Exception {
         // Configuration processed by ToolRunner
         Configuration conf = getConf();
         
         // Create a JobConf using the processed conf
         JobConf job = new JobConf(conf, MyApp.class);
         
         // Process custom command-line options
         Path in = new Path(args[1]);
         Path out = new Path(args[2]);
         
         // Specify various job-specific parameters     
         job.setJobName("my-app");
         job.setInputPath(in);
         job.setOutputPath(out);
         job.setMapperClass(MyApp.MyMapper.class);
         job.setReducerClass(MyApp.MyReducer.class);

         // Submit the job, then poll for progress until the job is complete
         JobClient.runJob(job);
       }
       
       public static void main(String[] args) throws Exception {
         // Let ToolRunner handle generic command-line options 
         int res = ToolRunner.run(new Configuration(), new Sort(), args);
         
         System.exit(res);
       }
     }
 

@see GenericOptionsParser @see ToolRunner]]>
Tool by {@link Tool#run(String[])}, after parsing with the given generic arguments. Uses the given Configuration, or builds one if null. Sets the Tool's configuration with the possibly modified version of the conf. @param conf Configuration for the Tool. @param tool Tool to run. @param args command-line arguments to the tool. @return exit code of the {@link Tool#run(String[])} method.]]> Tool with its Configuration. Equivalent to run(tool.getConf(), tool, args). @param tool Tool to run. @param args command-line arguments to the tool. @return exit code of the {@link Tool#run(String[])} method.]]> ToolRunner can be used to run classes implementing Tool interface. It works in conjunction with {@link GenericOptionsParser} to parse the generic hadoop command line arguments and modifies the Configuration of the Tool. The application-specific options are passed along without being modified.

@see Tool @see GenericOptionsParser]]>
this filter. @param nbHash The number of hash function to consider. @param hashType type of the hashing function (see {@link org.apache.hadoop.util.hash.Hash}).]]> Bloom filter, as defined by Bloom in 1970.

The Bloom filter is a data structure that was introduced in 1970 and that has been adopted by the networking research community in the past decade thanks to the bandwidth efficiencies that it offers for the transmission of set membership information between networked hosts. A sender encodes the information into a bit vector, the Bloom filter, that is more compact than a conventional representation. Computation and space costs for construction are linear in the number of elements. The receiver uses the filter to test whether various elements are members of the set. Though the filter will occasionally return a false positive, it will never return a false negative. When creating the filter, the sender can choose its desired point in a trade-off between the false positive rate and the size.

Originally created by European Commission One-Lab Project 034819. @see Filter The general behavior of a filter @see Space/Time Trade-Offs in Hash Coding with Allowable Errors]]> this filter. @param nbHash The number of hash function to consider. @param hashType type of the hashing function (see {@link org.apache.hadoop.util.hash.Hash}).]]> this counting Bloom filter.

Invariant: nothing happens if the specified key does not belong to this counter Bloom filter. @param key The key to remove.]]> key -> count map.

NOTE: due to the bucket size of this filter, inserting the same key more than 15 times will cause an overflow at all filter positions associated with this key, and it will significantly increase the error rate for this and other keys. For this reason the filter can only be used to store small count values 0 <= N << 15. @param key key to be tested @return 0 if the key is not present. Otherwise, a positive value v will be returned such that v == count with probability equal to the error rate of this filter, and v > count otherwise. Additionally, if the filter experienced an underflow as a result of {@link #delete(Key)} operation, the return value may be lower than the count with the probability of the false negative rate of such filter.]]> counting Bloom filter, as defined by Fan et al. in a ToN 2000 paper.

A counting Bloom filter is an improvement to standard a Bloom filter as it allows dynamic additions and deletions of set membership information. This is achieved through the use of a counting vector instead of a bit vector.

Originally created by European Commission One-Lab Project 034819. @see Filter The general behavior of a filter @see Summary cache: a scalable wide-area web cache sharing protocol]]> Builds an empty Dynamic Bloom filter. @param vectorSize The number of bits in the vector. @param nbHash The number of hash function to consider. @param hashType type of the hashing function (see {@link org.apache.hadoop.util.hash.Hash}). @param nr The threshold for the maximum number of keys to record in a dynamic Bloom filter row.]]> dynamic Bloom filter, as defined in the INFOCOM 2006 paper.

A dynamic Bloom filter (DBF) makes use of a s * m bit matrix but each of the s rows is a standard Bloom filter. The creation process of a DBF is iterative. At the start, the DBF is a 1 * m bit matrix, i.e., it is composed of a single standard Bloom filter. It assumes that nr elements are recorded in the initial bit vector, where nr <= n (n is the cardinality of the set A to record in the filter).

As the size of A grows during the execution of the application, several keys must be inserted in the DBF. When inserting a key into the DBF, one must first get an active Bloom filter in the matrix. A Bloom filter is active when the number of recorded keys, nr, is strictly less than the current cardinality of A, n. If an active Bloom filter is found, the key is inserted and nr is incremented by one. On the other hand, if there is no active Bloom filter, a new one is created (i.e., a new row is added to the matrix) according to the current size of A and the element is added in this new Bloom filter and the nr value of this new Bloom filter is set to one. A given key is said to belong to the DBF if the k positions are set to one in one of the matrix rows.

Originally created by European Commission One-Lab Project 034819. @see Filter The general behavior of a filter @see BloomFilter A Bloom filter @see Theory and Network Applications of Dynamic Bloom Filters]]> this filter. @param nbHash The number of hash functions to consider. @param hashType type of the hashing function (see {@link Hash}).]]> this filter. @param key The key to add.]]> this filter. @param key The key to test. @return boolean True if the specified key belongs to this filter. False otherwise.]]> this filter and a specified filter.

Invariant: The result is assigned to this filter. @param filter The filter to AND with.]]> this filter and a specified filter.

Invariant: The result is assigned to this filter. @param filter The filter to OR with.]]> this filter and a specified filter.

Invariant: The result is assigned to this filter. @param filter The filter to XOR with.]]> this filter.

The result is assigned to this filter.]]> this filter. @param keys The list of keys.]]> this filter. @param keys The collection of keys.]]> this filter. @param keys The array of keys.]]> this filter.]]> A filter is a data structure which aims at offering a lossy summary of a set A. The key idea is to map entries of A (also called keys) into several positions in a vector through the use of several hash functions.

Typically, a filter will be implemented as a Bloom filter (or a Bloom filter extension).

It must be extended in order to define the real behavior. @see Key The general behavior of a key @see HashFunction A hash function]]> Builds a hash function that must obey to a given maximum number of returned values and a highest value. @param maxValue The maximum highest returned value. @param nbHash The number of resulting hashed values. @param hashType type of the hashing function (see {@link Hash}).]]> this hash function. A NOOP]]> Builds a key with a default weight. @param value The byte value of this key.]]> Builds a key with a specified weight. @param value The value of this key. @param weight The weight associated to this key.]]> this key.]]> this key.]]> this key with a specified value. @param weight The increment.]]> this key by one.]]> The idea is to randomly select a bit to reset.]]> The idea is to select the bit to reset that will generate the minimum number of false negative.]]> The idea is to select the bit to reset that will remove the maximum number of false positive.]]> The idea is to select the bit to reset that will, at the same time, remove the maximum number of false positve while minimizing the amount of false negative generated.]]> Originally created by European Commission One-Lab Project 034819.]]> this filter. @param nbHash The number of hash function to consider. @param hashType type of the hashing function (see {@link org.apache.hadoop.util.hash.Hash}).]]> this retouched Bloom filter.

Invariant: if the false positive is null, nothing happens. @param key The false positive key to add.]]> this retouched Bloom filter. @param coll The collection of false positive.]]> this retouched Bloom filter. @param keys The list of false positive.]]> this retouched Bloom filter. @param keys The array of false positive.]]> this retouched Bloom filter. @param scheme The selective clearing scheme to apply.]]> retouched Bloom filter, as defined in the CoNEXT 2006 paper.

It allows the removal of selected false positives at the cost of introducing random false negatives, and with the benefit of eliminating some random false positives at the same time.

Originally created by European Commission One-Lab Project 034819. @see Filter The general behavior of a filter @see BloomFilter A Bloom filter @see RemoveScheme The different selective clearing algorithms @see Retouched Bloom Filters: Allowing Networked Applications to Trade Off Selected False Positives Against False Negatives]]> length, and the provided seed value @param bytes input bytes @param length length of the valid bytes to consider @param initval seed value @return hash value]]> The best hash table sizes are powers of 2. There is no need to do mod a prime (mod is sooo slow!). If you need less than 32 bits, use a bitmask. For example, if you need only 10 bits, do h = (h & hashmask(10)); In which case, the hash table should have hashsize(10) elements.

If you are hashing n strings byte[][] k, do it like this: for (int i = 0, h = 0; i < n; ++i) h = hash( k[i], h);

By Bob Jenkins, 2006. bob_jenkins@burtleburtle.net. You may use this code any way you wish, private, educational, or commercial. It's free.

Use for hash table lookup, or anything where one collision in 2^^32 is acceptable. Do NOT use for cryptographic purposes.]]> lookup3.c, by Bob Jenkins, May 2006, Public Domain. You can use this free for any purpose. It's in the public domain. It has no warranty. @see lookup3.c @see Hash Functions (and how this function compares to others such as CRC, MD?, etc @see Has update on the Dr. Dobbs Article]]> The C version of MurmurHash 2.0 found at that site was ported to Java by Andrzej Bialecki (ab at getopt org).

]]>