# Suggestions on how best to cache TransportClient
**URL:** https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368
**Category:** Elasticsearch
**Created:** [January 12, 2012, 8:38pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368 "2012-01-12T20:38:30Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Shane\_Witbeck](https://discuss.elastic.co/u/Shane_Witbeck)
#### Post date: [January 12, 2012, 8:38pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/1 "2012-01-12T20:38:30Z")
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](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
---
### Author:  [@dadoonet](https://discuss.elastic.co/u/dadoonet)
#### Post date: [January 12, 2012, 8:44pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/2 "2012-01-12T20:44:39Z")
As you are using Spring did you look at this factory ? [https://github.com/erezmazor/projectx/tree/master/org.projectx.elasticsearch](https://github.com/erezmazor/projectx/tree/master/org.projectx.elasticsearch)
David.
De : [elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com) [[mailto:elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com)] De la part de Shane Witbeck
Envoyé : jeudi 12 janvier 2012 21:39
À : [elasticsearch@googlegroups.com](mailto: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](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
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [January 12, 2012, 9:58pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/3 "2012-01-12T21:58:04Z")
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](mailto: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](https://github.com/erezmazor/projectx/tree/master/org.projectx.elasticsearch)
>
> * * *
>
> * * *
>
> David.\*\*\*\*
>
> * * *
>
> _De :_ [elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com) [mailto:
> [elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com)] _De la part de_ Shane Witbeck
> _Envoyé :_ jeudi 12 janvier 2012 21:39
> _À :_ [elasticsearch@googlegroups.com](mailto: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:
> [getClient · GitHub](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\*\*\*\*
>
> * * *
>
> * * *
---
### Author:  [@Shane\_Witbeck](https://discuss.elastic.co/u/Shane_Witbeck)
#### Post date: [January 13, 2012, 2:48pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/4 "2012-01-13T14:48:34Z")
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?
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [January 14, 2012, 4:12pm UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/5 "2012-01-14T16:12:08Z")
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.com](mailto:shane@digitalsanctum.com)wrote:
> 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?
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 3:42am UTC](https://discuss.elastic.co/t/suggestions-on-how-best-to-cache-transportclient/6368/6 "2017-07-06T03:42:43Z")