Suggestions on how best to cache TransportClient


(Shane Witbeck) #1

I'm using ES in a Spring web app. I'm working on improving performance and
found that getting the TransportClient is generally taking longer than the
actual search execution itself. Here's what I'm doing now:

  1. Using the Java API, build a FilteredQueryBuilder
  2. Get an instance of TransportClient something like this:
    https://gist.github.com/1602928
  3. execute the search via SearchRequestBuilder.execute.actionGet()
  4. close the TransportClient
  5. process the SearchResponse

Is there a specific way of caching the TransportClient and reusing it
between search requests?

Thanks


(David Pilato) #2

As you are using Spring did you look at this factory ? https://github.com/erezmazor/projectx/tree/master/org.projectx.elasticsearch

David.

De : elasticsearch@googlegroups.com [mailto:elasticsearch@googlegroups.com] De la part de Shane Witbeck
Envoyé : jeudi 12 janvier 2012 21:39
À : elasticsearch@googlegroups.com
Objet : suggestions on how best to cache TransportClient

I'm using ES in a Spring web app. I'm working on improving performance and found that getting the TransportClient is generally taking longer than the actual search execution itself. Here's what I'm doing now:

  1. Using the Java API, build a FilteredQueryBuilder
  2. Get an instance of TransportClient something like this: https://gist.github.com/1602928
  3. execute the search via SearchRequestBuilder.execute.actionGet()
  4. close the TransportClient
  5. process the SearchResponse

Is there a specific way of caching the TransportClient and reusing it between search requests?

Thanks


(Shay Banon) #3

The Java Client needs to be kept around for the duration of the app. Its
threadsafe and "heavy". Just have a factory bean that is a singleton that
creates the client.

On Thu, Jan 12, 2012 at 10:44 PM, David Pilato david@pilato.fr wrote:

As you are using Spring did you look at this factory ?
https://github.com/erezmazor/projectx/tree/master/org.projectx.elasticsearch



David.****


De : elasticsearch@googlegroups.com [mailto:
elasticsearch@googlegroups.com] De la part de Shane Witbeck
Envoyé : jeudi 12 janvier 2012 21:39
À : elasticsearch@googlegroups.com
Objet : suggestions on how best to cache TransportClient****


I'm using ES in a Spring web app. I'm working on improving performance and
found that getting the TransportClient is generally taking longer than the
actual search execution itself. Here's what I'm doing now:****

  1. Using the Java API, build a FilteredQueryBuilder****
  2. Get an instance of TransportClient something like this:
    https://gist.github.com/1602928****
  3. execute the search via SearchRequestBuilder.execute.actionGet()****
  4. close the TransportClient****
  5. process the SearchResponse****

Is there a specific way of caching the TransportClient and reusing it
between search requests?****


Thanks****




(Shane Witbeck) #4

Thanks for the replies. I already had a factory bean that would create a
new client for each ES operation. I've updated that factory to simply
initialize a shared client once on app start-up which performs well but
doesn't handle the case where ES or connectivity to ES is not available. To
address this, I'd like to build a retry mechanism to establish a working
client. Any special considerations needed here?


(Shay Banon) #5

It automatically retries in the background to connect to the listed nodes.

On Fri, Jan 13, 2012 at 4:48 PM, Shane Witbeck shane@digitalsanctum.comwrote:

Thanks for the replies. I already had a factory bean that would create a
new client for each ES operation. I've updated that factory to simply
initialize a shared client once on app start-up which performs well but
doesn't handle the case where ES or connectivity to ES is not available. To
address this, I'd like to build a retry mechanism to establish a working
client. Any special considerations needed here?


(system) #6