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.
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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.