Java API TransportClient Threadpool

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Java API TransportClient Threadpool

Abid Hussain
Hi all,

I would like to understand how TransportClient works in terms of how it uses it's thread pool.
  • As it uses a threadpool I assume that every request is performed in it's own thread - is that correct?
  • If so, does that mean that i.e. it's pool size is 20 and 21 search requests are coming at the same time the 21st one has to wait until one of the 20 running requests are finished?
And, finally: why does it use a thread pool at all? I mean, all the work is done on server side and when I think of database clients I would have rather expected something like a connection pool.

Best Regards,

Abid


--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6bd05293-03f7-417e-9801-a5a6748bc1db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Java API TransportClient Threadpool

joergprante@gmail.com
There is a connection pool. Netty connections are pooled, they can connect to multiple nodes at the same time.

All requests are submitted asynchronously. It means, submitting and receiving may happen on different threads. They do not block.

Jörg

On Wed, Mar 18, 2015 at 8:47 AM, Abid Hussain <[hidden email]> wrote:
Hi all,

I would like to understand how TransportClient works in terms of how it uses it's thread pool.
  • As it uses a threadpool I assume that every request is performed in it's own thread - is that correct?
  • If so, does that mean that i.e. it's pool size is 20 and 21 search requests are coming at the same time the 21st one has to wait until one of the 20 running requests are finished?
And, finally: why does it use a thread pool at all? I mean, all the work is done on server side and when I think of database clients I would have rather expected something like a connection pool.

Best Regards,

Abid


--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6bd05293-03f7-417e-9801-a5a6748bc1db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGsky2s5NoszHsSM%2BF0cwnzkgVTsVCw317N2ey%3DwUX07A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re[2]: Java API TransportClient Threadpool

Александр Свиридов
Can you say how we can configure this pool?


Среда, 18 марта 2015, 9:10 +01:00 от "[hidden email]" <[hidden email]>:
There is a connection pool. Netty connections are pooled, they can connect to multiple nodes at the same time.

All requests are submitted asynchronously. It means, submitting and receiving may happen on different threads. They do not block.

Jörg

On Wed, Mar 18, 2015 at 8:47 AM, Abid Hussain <hussain@...> wrote:
Hi all,

I would like to understand how TransportClient works in terms of how it uses it's thread pool.
  • As it uses a threadpool I assume that every request is performed in it's own thread - is that correct?
  • If so, does that mean that i.e. it's pool size is 20 and 21 search requests are coming at the same time the 21st one has to wait until one of the 20 running requests are finished?
And, finally: why does it use a thread pool at all? I mean, all the work is done on server side and when I think of database clients I would have rather expected something like a connection pool.

Best Regards,

Abid


--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6bd05293-03f7-417e-9801-a5a6748bc1db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGsky2s5NoszHsSM%2BF0cwnzkgVTsVCw317N2ey%3DwUX07A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/1426666581.846598748%40f177.i.mail.ru.
For more options, visit https://groups.google.com/d/optout.