Thanks Ivan and Denis for clarifying things. I think we are in good shape :)
Thanks, Raymond On Tue, Jun 30, 2020 at 10:29 AM Denis Magda <dma...@apache.org> wrote: > 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/ > > > -- <http://www.trimble.com/> Raymond Wilson Solution Architect, Civil Construction Software Systems (CCSS) 11 Birmingham Drive | Christchurch, New Zealand +64-21-2013317 Mobile raymond_wil...@trimble.com <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
