Client Nodes - Efficiency

Elastic Stack Elasticsearch
1

I am deploying an embedded version of ES in a web application, where there
is one data node created. If I start up another instance of the web
application, another data node is created for that instance and both data
nodes will cluster.

I have a cron job which will kick off periodically in the same JVM (but
potentially different classloader) which will need to access the ES cluster.
The job will instantiate, establish a connection to ES, read/write, then
terminate. My Cron job will have no way to ask the esServer for a client,
nor will it have access to the elasticsearch.properties which was used to
configure the server.

I imagine that some settings (like the name of the cluster) are imperatives,
but I am trying to configure this node with as little information as
possible so there isn't a lot of effort syncing settings between the ES data
node and this node. Since it isn't a data node, I am assuming that settings
related to mappings, index storage, and others are not applicable.

It seems like a TransportClient might be the best approach since it doesn't
require configuration and 'localhost:9300' should always point to the local
data node.

var client = new TransportClient().addTransportAddress(new
InetSocketTransportAddress('localhost', 9300));
...
client.close();

So what is the most effective way to connect to an existing data node when
you are on the same JVM, but may be in a different classloader?

2

That would be it. Note you still need to set the cluster name, even with the transport client. A node client will be more optimized then the transport client, but it really depends on what you are doing and if you really need it.
On Tuesday, May 10, 2011 at 7:35 PM, James Cook wrote:

I am deploying an embedded version of ES in a web application, where there is one data node created. If I start up another instance of the web application, another data node is created for that instance and both data nodes will cluster.

I have a cron job which will kick off periodically in the same JVM (but potentially different classloader) which will need to access the ES cluster. The job will instantiate, establish a connection to ES, read/write, then terminate. My Cron job will have no way to ask the esServer for a client, nor will it have access to the elasticsearch.properties which was used to configure the server.

I imagine that some settings (like the name of the cluster) are imperatives, but I am trying to configure this node with as little information as possible so there isn't a lot of effort syncing settings between the ES data node and this node. Since it isn't a data node, I am assuming that settings related to mappings, index storage, and others are not applicable.

It seems like a TransportClient might be the best approach since it doesn't require configuration and 'localhost:9300' should always point to the local data node.

var client = new TransportClient().addTransportAddress(new InetSocketTransportAddress('localhost', 9300));
...
client.close();

So what is the most effective way to connect to an existing data node when you are on the same JVM, but may be in a different classloader?

3

Is there a corresponding initialization technique for a non-data node client
which would initialize it similar to how I am using the TransportClient?
Basically, I know the name of the cluster and the fact that a data node is
published at localhost:9300.

On Tue, May 10, 2011 at 3:37 PM, Shay Banon shay.banon@elasticsearch.comwrote:

That would be it. Note you still need to set the cluster name, even with
the transport client. A node client will be more optimized then the
transport client, but it really depends on what you are doing and if you
really need it.

On Tuesday, May 10, 2011 at 7:35 PM, James Cook wrote:

I am deploying an embedded version of ES in a web application, where there
is one data node created. If I start up another instance of the web
application, another data node is created for that instance and both data
nodes will cluster.

I have a cron job which will kick off periodically in the same JVM (but
potentially different classloader) which will need to access the ES cluster.
The job will instantiate, establish a connection to ES, read/write, then
terminate. My Cron job will have no way to ask the esServer for a client,
nor will it have access to the elasticsearch.properties which was used to
configure the server.

I imagine that some settings (like the name of the cluster) are
imperatives, but I am trying to configure this node with as little
information as possible so there isn't a lot of effort syncing settings
between the ES data node and this node. Since it isn't a data node, I am
assuming that settings related to mappings, index storage, and others are
not applicable.

It seems like a TransportClient might be the best approach since it doesn't
require configuration and 'localhost:9300' should always point to the local
data node.

var client = new TransportClient().addTransportAddress(new
InetSocketTransportAddress('localhost', 9300));
...
client.close();

So what is the most effective way to connect to an existing data node when
you are on the same JVM, but may be in a different classloader?

4

Did not understand the question.
On Tuesday, May 10, 2011 at 11:45 PM, James Cook wrote:

Is there a corresponding initialization technique for a non-data node client which would initialize it similar to how I am using the TransportClient? Basically, I know the name of the cluster and the fact that a data node is published at localhost:9300.

On Tue, May 10, 2011 at 3:37 PM, Shay Banon shay.banon@elasticsearch.com wrote:

That would be it. Note you still need to set the cluster name, even with the transport client. A node client will be more optimized then the transport client, but it really depends on what you are doing and if you really need it.
On Tuesday, May 10, 2011 at 7:35 PM, James Cook wrote:

I am deploying an embedded version of ES in a web application, where there is one data node created. If I start up another instance of the web application, another data node is created for that instance and both data nodes will cluster.

I have a cron job which will kick off periodically in the same JVM (but potentially different classloader) which will need to access the ES cluster. The job will instantiate, establish a connection to ES, read/write, then terminate. My Cron job will have no way to ask the esServer for a client, nor will it have access to the elasticsearch.properties which was used to configure the server.

I imagine that some settings (like the name of the cluster) are imperatives, but I am trying to configure this node with as little information as possible so there isn't a lot of effort syncing settings between the ES data node and this node. Since it isn't a data node, I am assuming that settings related to mappings, index storage, and others are not applicable.

It seems like a TransportClient might be the best approach since it doesn't require configuration and 'localhost:9300' should always point to the local data node.

var client = new TransportClient().addTransportAddress(new InetSocketTransportAddress('localhost', 9300));
...
client.close();

So what is the most effective way to connect to an existing data node when you are on the same JVM, but may be in a different classloader?

5

I withdraw the question. :slight_smile:

On Tue, May 10, 2011 at 5:09 PM, Shay Banon shay.banon@elasticsearch.comwrote:

Did not understand the question.

On Tuesday, May 10, 2011 at 11:45 PM, James Cook wrote:

Is there a corresponding initialization technique for a non-data node
client which would initialize it similar to how I am using the
TransportClient? Basically, I know the name of the cluster and the fact that
a data node is published at localhost:9300.

On Tue, May 10, 2011 at 3:37 PM, Shay Banon shay.banon@elasticsearch.comwrote:

That would be it. Note you still need to set the cluster name, even with
the transport client. A node client will be more optimized then the
transport client, but it really depends on what you are doing and if you
really need it.

On Tuesday, May 10, 2011 at 7:35 PM, James Cook wrote:

I am deploying an embedded version of ES in a web application, where there
is one data node created. If I start up another instance of the web
application, another data node is created for that instance and both data
nodes will cluster.

I have a cron job which will kick off periodically in the same JVM (but
potentially different classloader) which will need to access the ES cluster.
The job will instantiate, establish a connection to ES, read/write, then
terminate. My Cron job will have no way to ask the esServer for a client,
nor will it have access to the elasticsearch.properties which was used to
configure the server.

I imagine that some settings (like the name of the cluster) are
imperatives, but I am trying to configure this node with as little
information as possible so there isn't a lot of effort syncing settings
between the ES data node and this node. Since it isn't a data node, I am
assuming that settings related to mappings, index storage, and others are
not applicable.

It seems like a TransportClient might be the best approach since it doesn't
require configuration and 'localhost:9300' should always point to the local
data node.

var client = new TransportClient().addTransportAddress(new
InetSocketTransportAddress('localhost', 9300));
...
client.close();

So what is the most effective way to connect to an existing data node when
you are on the same JVM, but may be in a different classloader?