# Client Nodes - Efficiency **URL:** \ **Category:** Elasticsearch\ **Created:** [May 10, 2011, 4:35pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376 "2011-05-10T16:35:57Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![James\_Cook\_2](https://avatars.discourse-cdn.com/v4/letter/j/b19c9b/32.png) [@James\_Cook\_2](https://discuss.elastic.co/u/James_Cook_2)\ **Post date:** [May 10, 2011, 4:35pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/1 "2011-05-10T16:35:57Z")
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? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [May 10, 2011, 7:37pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/2 "2011-05-10T19:37:04Z")
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? ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [May 10, 2011, 8:45pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/3 "2011-05-10T20:45:01Z")
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](mailto: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? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [May 10, 2011, 9:09pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/4 "2011-05-10T21:09:33Z")
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](mailto: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? ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [May 11, 2011, 1:07pm UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/5 "2011-05-11T13:07:29Z")
I withdraw the question. 🙂 - - On Tue, May 10, 2011 at 5:09 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > 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](mailto: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? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:06am UTC](https://discuss.elastic.co/t/client-nodes-efficiency/4376/6 "2017-07-06T04:06:29Z")