You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The feeder mode was broken due to wrong classpath control in the example shell scripts
and the river state move into the cluster state. Cluster state is not possible
to use in TransportClient, so a workaround was introduced to let the JDBC plugin
start also in a TransportClient.
More comments added at example shell scripts to clarify the use of feeder mode
in a JVM outside of an Elasticsearch node.
Update to Elasticsearch 1.3.1
An NPE in the river state getting should be fixed.
Dropping unused dependency of hamcrest matchers.
.put("name", "feeder") // prevents lookup of names.txt, we don't have it, and marks this node as "feeder". See also module load skipping in JDBCRiverPlugin
418
+
.put("network.server", false) // this is not a server
419
+
.put("node.client", true) // this is an Elasticearch client
420
+
.put("cluster.name", URIUtil.parseQueryString(connectionSpec).get("es.cluster.name")) // specified remote ES cluster
421
+
.put("client.transport.sniff", false) // we do not sniff (should be configurable)
422
+
.put("client.transport.ignore_cluster_name", false) // respect cluster name setting
423
+
.put("client.transport.ping_timeout", "30s") // large ping timeout (should not be required)
424
+
.put("client.transport.nodes_sampler_interval", "30s") // only for sniff sampling
425
+
.put("path.plugins", ".dontexist") // pointing to a non-exiting folder means, this disables loading site plugins
426
+
// we do not need to change class path settings when using the "feeder" name trick
0 commit comments