[[hdfs-component]]
= HDFS Component (deprecated)
:page-source: components/camel-hdfs/src/main/docs/hdfs-component.adoc

*Available as of Camel version 2.8*


The *hdfs* component enables you to read and write messages from/to an
HDFS file system. HDFS is the distributed file system at the heart of
http://hadoop.apache.org[Hadoop].

Maven users will need to add the following dependency to their `pom.xml`
for this component:

[source,xml]
------------------------------------------------------------
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-hdfs</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>
------------------------------------------------------------

== URI format

[source,java]
---------------------------------------
hdfs://hostname[:port][/path][?options]
---------------------------------------

You can append query options to the URI in the following format,
`?option=value&option=value&...`

 The path is treated in the following way:

1.  as a consumer, if it's a file, it just reads the file, otherwise if
it represents a directory it scans all the file under the path
satisfying the configured pattern. All the files under that directory
must be of the same type.
2.  as a producer, if at least one split strategy is defined, the path
is considered a directory and under that directory the producer creates
a different file per split named using the configured
UuidGenerator.

*Note*

When consuming from hdfs then in normal mode, a file is split into
chunks, producing a message per chunk. You can configure the size of the
chunk using the chunkSize option. If you want to read from hdfs and
write to a regular file using the file component, then you can use the
fileMode=Append to append each of the chunks together.

 

== Options




// component options: START
The HDFS component supports 2 options, which are listed below.



[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *jAASConfiguration* (common) | To use the given configuration for security with JAAS. |  | Configuration
| *resolveProperty Placeholders* (advanced) | Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. | true | boolean
|===
// component options: END







// endpoint options: START
The HDFS endpoint is configured using URI syntax:

----
hdfs:hostName:port/path
----

with the following path and query parameters:

=== Path Parameters (3 parameters):


[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *hostName* | *Required* HDFS host to use |  | String
| *port* | HDFS port to use | 8020 | int
| *path* | *Required* The directory path to use |  | String
|===


=== Query Parameters (38 parameters):


[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *connectOnStartup* (common) | Whether to connect to the HDFS file system on starting the producer/consumer. If false then the connection is created on-demand. Notice that HDFS may take up till 15 minutes to establish a connection, as it has hardcoded 45 x 20 sec redelivery. By setting this option to false allows your application to startup, and not block for up till 15 minutes. | true | boolean
| *fileSystemType* (common) | Set to LOCAL to not use HDFS but local java.io.File instead. | HDFS | HdfsFileSystemType
| *fileType* (common) | The file type to use. For more details see Hadoop HDFS documentation about the various files types. | NORMAL_FILE | HdfsFileType
| *keyType* (common) | The type for the key in case of sequence or map files. | NULL | WritableType
| *owner* (common) | The file owner must match this owner for the consumer to pickup the file. Otherwise the file is skipped. |  | String
| *valueType* (common) | The type for the key in case of sequence or map files | BYTES | WritableType
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
| *delay* (consumer) | The interval (milliseconds) between the directory scans. | 1000 | long
| *initialDelay* (consumer) | For the consumer, how much to wait (milliseconds) before to start scanning the directory. |  | long
| *pattern* (consumer) | The pattern used for scanning the directory | * | String
| *sendEmptyMessageWhenIdle* (consumer) | If the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead. | false | boolean
| *exceptionHandler* (consumer) | To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |  | ExceptionHandler
| *exchangePattern* (consumer) | Sets the exchange pattern when the consumer creates an exchange. |  | ExchangePattern
| *pollStrategy* (consumer) | A pluggable org.apache.camel.PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation before an Exchange have been created and being routed in Camel. |  | PollingConsumerPoll Strategy
| *append* (producer) | Append to existing file. Notice that not all HDFS file systems support the append option. | false | boolean
| *overwrite* (producer) | Whether to overwrite existing files with the same name | true | boolean
| *blockSize* (advanced) | The size of the HDFS blocks | 67108864 | long
| *bufferSize* (advanced) | The buffer size used by HDFS | 4096 | int
| *checkIdleInterval* (advanced) | How often (time in millis) in to run the idle checker background task. This option is only in use if the splitter strategy is IDLE. | 500 | int
| *chunkSize* (advanced) | When reading a normal file, this is split into chunks producing a message per chunk. | 4096 | int
| *compressionCodec* (advanced) | The compression codec to use | DEFAULT | HdfsCompressionCodec
| *compressionType* (advanced) | The compression type to use (is default not in use) | NONE | CompressionType
| *openedSuffix* (advanced) | When a file is opened for reading/writing the file is renamed with this suffix to avoid to read it during the writing phase. | opened | String
| *readSuffix* (advanced) | Once the file has been read is renamed with this suffix to avoid to read it again. | read | String
| *replication* (advanced) | The HDFS replication factor | 3 | short
| *splitStrategy* (advanced) | In the current version of Hadoop opening a file in append mode is disabled since it's not very reliable. So, for the moment, it's only possible to create new files. The Camel HDFS endpoint tries to solve this problem in this way: If the split strategy option has been defined, the hdfs path will be used as a directory and files will be created using the configured UuidGenerator. Every time a splitting condition is met, a new file is created. The splitStrategy option is defined as a string with the following syntax: splitStrategy=ST:value,ST:value,... where ST can be: BYTES a new file is created, and the old is closed when the number of written bytes is more than value MESSAGES a new file is created, and the old is closed when the number of written messages is more than value IDLE a new file is created, and the old is closed when no writing happened in the last value milliseconds |  | String
| *synchronous* (advanced) | Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). | false | boolean
| *backoffErrorThreshold* (scheduler) | The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in. |  | int
| *backoffIdleThreshold* (scheduler) | The number of subsequent idle polls that should happen before the backoffMultipler should kick-in. |  | int
| *backoffMultiplier* (scheduler) | To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. |  | int
| *greedy* (scheduler) | If greedy is enabled, then the ScheduledPollConsumer will run immediately again, if the previous run polled 1 or more messages. | false | boolean
| *runLoggingLevel* (scheduler) | The consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that. | TRACE | LoggingLevel
| *scheduledExecutorService* (scheduler) | Allows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. |  | ScheduledExecutor Service
| *scheduler* (scheduler) | To use a cron scheduler from either camel-spring or camel-quartz2 component | none | ScheduledPollConsumer Scheduler
| *schedulerProperties* (scheduler) | To configure additional properties when using a custom scheduler or any of the Quartz2, Spring based scheduler. |  | Map
| *startScheduler* (scheduler) | Whether the scheduler should be auto started. | true | boolean
| *timeUnit* (scheduler) | Time unit for initialDelay and delay options. | MILLISECONDS | TimeUnit
| *useFixedDelay* (scheduler) | Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details. | true | boolean
|===
// endpoint options: END
// spring-boot-auto-configure options: START
== Spring Boot Auto-Configuration

When using Spring Boot make sure to use the following Maven dependency to have support for auto configuration:

[source,xml]
----
<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-hdfs-starter</artifactId>
  <version>x.x.x</version>
  <!-- use the same version as your Camel core version -->
</dependency>
----


The component supports 3 options, which are listed below.



[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *camel.component.hdfs.enabled* | Enable hdfs component | true | Boolean
| *camel.component.hdfs.j-a-a-s-configuration* | To use the given configuration for security with JAAS. The option is a javax.security.auth.login.Configuration type. |  | String
| *camel.component.hdfs.resolve-property-placeholders* | Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. | true | Boolean
|===
// spring-boot-auto-configure options: END






=== KeyType and ValueType

* NULL it means that the key or the value is absent
* BYTE for writing a byte, the java Byte class is mapped into a BYTE
* BYTES for writing a sequence of bytes. It maps the java ByteBuffer
class
* INT for writing java integer
* FLOAT for writing java float
* LONG for writing java long
* DOUBLE for writing java double
* TEXT for writing java strings

BYTES is also used with everything else, for example, in Camel a file is
sent around as an InputStream, int this case is written in a sequence
file or a map file as a sequence of bytes.

== Splitting Strategy

In the current version of Hadoop opening a file in append mode is
disabled since it's not very reliable. So, for the moment, it's only
possible to create new files. The Camel HDFS endpoint tries to solve
this problem in this way:

* If the split strategy option has been defined, the hdfs path will be
used as a directory and files will be created using the configured
UuidGenerator
* Every time a splitting condition is met, a new file is created.

 The splitStrategy option is defined as a string with the following
syntax:

 splitStrategy=<ST>:<value>,<ST>:<value>,*

where <ST> can be:

* BYTES a new file is created, and the old is closed when the number of
written bytes is more than <value>
* MESSAGES a new file is created, and the old is closed when the number
of written messages is more than <value>
* IDLE a new file is created, and the old is closed when no writing
happened in the last <value> milliseconds

*Note*

note that this strategy currently requires either setting an IDLE value
or setting the HdfsConstants.HDFS_CLOSE header to false to use the
BYTES/MESSAGES configuration...otherwise, the file will be closed with
each message

for example:

[source,java]
----------------------------------------------------------------
hdfs://localhost/tmp/simple-file?splitStrategy=IDLE:1000,BYTES:5
----------------------------------------------------------------

it means: a new file is created either when it has been idle for more
than 1 second or if more than 5 bytes have been written. So, running
`hadoop fs -ls /tmp/simple-file` you'll see that multiple files have
been created.

== Message Headers

The following headers are supported by this component:

=== Producer only

[width="100%",cols="10%,90%",options="header",]
|=======================================================================
|Header |Description

|`CamelFileName` |*Camel 2.13:* Specifies the name of the file to write (relative to the
endpoint path). The name can be a `String` or an
Expression object. Only relevant when not using a
split strategy.
|=======================================================================

== Controlling to close file stream

*Available as of Camel 2.10.4*

When using the xref:hdfs-component.adoc[HDFS] producer *without* a split strategy,
then the file output stream is by default closed after the write.
However you may want to keep the stream open, and only explicitly close
the stream later. For that you can use the header
`HdfsConstants.HDFS_CLOSE` (value = `"CamelHdfsClose"`) to control this.
Setting this value to a boolean allows you to explicit control whether
the stream should be closed or not.

Notice this does not apply if you use a split strategy, as there are
various strategies that can control when the stream is closed.

== Using this component in OSGi

This component is fully functional in an OSGi environment, however, it
requires some actions from the user. Hadoop uses the thread context
class loader in order to load resources. Usually, the thread context
classloader will be the bundle class loader of the bundle that contains
the routes. So, the default configuration files need to be visible from
the bundle class loader. A typical way to deal with it is to keep a copy
of core-default.xml in your bundle root. That file can be found in the
hadoop-common.jar.
