You don't have to worry about this as Flink takes care of all of this.
I was just trying to explain what the query threads are there for. If
we would only use the network threads for the queries, these might be
blocked during queries and hence not answer network events. But since
we use these two
Hi Aljoscha, Ufuk
Thank you for the replies.
I'm using RocksDB state backend. Could you please explain the blocking I/O
calls mentioned?
when will it happen? And what will be the effect? A timeout exception?
Best
Ziyad
On Mon, Aug 14, 2017 at 10:17 PM, Ufuk Celebi wrote:
> This is as Aljosch
This is as Aljoscha describes. Each thread can handle many different
clients at the same time. You shouldn't need to change the defaults in
most cases.
The network threads handle the TCP connections and dispatch query
tasks to the query threads which do the actual querying of the state
backend. In
Hi,
I think the number of network treads and number of query threads only roughly
correlate with the number of clients that can query in parallel since this is
using asynchronous communication via Akka/Netty. Of course, increasing that
number means there can be more connections but I think even
Hi all,
I'm trying to understand how many parallel clients will be supported by the
queryable state.
- query.server.network-threads: number of network (event loop) threads
for the KvStateServer (0 => #slots)
- query.server.query-threads: number of asynchronous query threads for
the K
