Hi Raymond, You will not come across any internode-communication issues with your deployment configuration as long as the servers and clients are running withing the K8 environment.
The issue, discussed here, takes place if one of the following happens: - The clients are deployed in K8 while the servers are running on virtual machines (or vice versa). - A serverless function attempts to use a thick client that by the current design creates a ServerSocket connection: https://issues.apache.org/jira/browse/IGNITE-13013 As for the continuous queries, I have the following use case that can easily fail. Let's say your 10 servers are running on virtual machines while a thick client is managed by K8. The client registers a CQ in the cluster and all 10 servers at some point in time will need to send an update notification to the client. To do that, they have to open a connection with the client, and here the things can fall apart. - Denis On Fri, Jun 26, 2020 at 11:54 PM Raymond Wilson <raymond_wil...@trimble.com> wrote: > I have just caught up with this discussion and wanted to outline a set of > use > cases we have that rely on server nodes communicating with client nodes. > > Firstly, I'd like to confirm my mental model of server & client nodes > within > a grid (ignoring thin clients for now): > > A grid contains a set of nodes somewhat arbitrarily labelled 'server' and > 'client' where the distinction of a 'server' node is that it is responsible > for containing data (in-memory only, or also with persistence). Apart from > that distinction, all nodes are essentially peers in the grid and may use > the messaging fabric, compute layer and other grid features on an equal > footing. > > In our solution we leverage these capabilities to build and orchestrate > complex analytics queries that utilise compute functions that are initiated > in three distinct ways: client -> client, client -> server and server -> > client, and where all three styles of initiation are using within a single > analytics request made to the grid it self. I can go into more detail about > the exact sequencing of these activities if you like, but it may be > sufficient to know they are used to reason about the problem statement and > proposals outlined here. > > Our infrastructure is deployed to Kubernetes using EKS on AWS, and all > three > relationships between client and server nodes noted above function well > (caveat: we do see odd things though such as long pauses on critical worker > threads, and occasional empty topology warnings when locating client nodes > to send requests to). We also use continuous queries in three contexts (all > within server nodes). > > If this thread is suggesting changing the functional relationship between > server and client nodes then this may have impacts on our architecture and > implementation that we will need to consider. > > This thread has highlighted issues with K8s deployments and also CQ issues. > The suggestion is that Server to Client just doesn't work on K8s, which > does > not agree with our experience of it working. I'd also like to understand > better the bounds of the issue with CQ: When does it not work and what are > the symptoms we would see if there was an issue with the way we are using > it, or the K8s infrastructure we deploy to? > > Thanks, > Raymond. > > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
