RiverSource, RiverMouth, and RiverFlow

errolc edited this page Oct 24, 2014 · 5 revisions

The JDBC river consists of three conceptual interfaces than can be implemented separately.

When you use the strategy parameter, the JDBC river tries to load additional classes before falling back to the simple strategy.

You can implement your own strategy by adding your implementation jars to the plugin folder and exporting the implementing classes in the META-INF/services directory. The RiverService looks up implementations for your favorite strategy before the JDBC river initializes.

So, it is easy to reuse or replace existing code, or adapt your own JDBC retrieval strategy to the core JDBC river.


The river source models the data producing side. Beside defining the JDBC connect parameters, it manages a dual-channel connection to the data producer for reading and for writing. The reading channel is used for fetching data, while the writing channel can update the source.

The RiverSource API can be inspected at http://jprante.github.io/elasticsearch-river-jdbc/apidocs/org/xbib/elasticsearch/river/jdbc/RiverSource.html


The RiverMouth is the abstraction of the destination where all the data is flowing from the river source. It controls the resource usage of the bulk indexing method of Elasticsearch. Throttling is possible by limiting the number of bulk actions per request or by the maximum number of concurrent request.

The RiverMouth API can be inspected at http://jprante.github.io/elasticsearch-river-jdbc/apidocs/org/xbib/elasticsearch/river/jdbc/RiverMouth.html


The RiverFlow is the abstraction to the thread which performs data fetching from the river source and transports it to the river mouth. A 'move' is considered a single step in the river live cycle. A river flow can be aborted.

The RiverFlow API can be inspected at http://jprante.github.io/elasticsearch-river-jdbc/apidocs/org/xbib/elasticsearch/river/jdbc/RiverFlow.html

For more information, consult the source code or the Java docs: