Great, thanks Denis. I had no idea the thin client existed. This should be exactly what we need.
From: Denis Mekhanikov <dmekhani...@gmail.com> Sent: Friday, August 3, 2018 7:31 PM To: user@ignite.apache.org Subject: Re: Cache updates to nodes in client mode Gordon, Client nodes are not developed to be used on user side of the application. Thin client should be used instead: https://apacheignite-net.readme.io/docs/thin-client Also ODBC client may be an option here: https://apacheignite-sql.readme.io/docs/odbc-driver Denis пт, 3 авг. 2018 г. в 10:13, Gordon Reid (Nine Mile) <gordon.r...@ninemilefinancial.com<mailto:gordon.r...@ninemilefinancial.com>>: Thanks Denis. Yes, I know about this setting. Actually, the problem really is that when a client is trying to 1. Reconnect after a problem 2. Or even just connect for the first time on start up Then the updates to other nodes will pause while this new client is joining the cluster. Is there any way to prevent that? Imagine if we have 50 users, and each time one of them opens their GUI, the updates to all GUIs will pause until the connection is complete. Thanks, Gordon. From: Denis Mekhanikov <dmekhani...@gmail.com<mailto:dmekhani...@gmail.com>> Sent: Wednesday, August 1, 2018 10:28 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Cache updates to nodes in client mode Gordon, There is already a mechanism in discovery protocol, that makes client nodes to be disconnected from cluster in case, when they don't respond for a long time. It can be configured using IgniteConfiguration#clientFailureDetectionTimeout<https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setClientFailureDetectionTimeout-long->. More information on it: https://apacheignite.readme.io/docs/tcpip-discovery#section-failure-detection-timeout But currently this functionality is broken: IGNITE-5103<https://issues.apache.org/jira/browse/IGNITE-5103> It is going to be fixed in Ignite 2.7 Denis ср, 1 авг. 2018 г. в 2:20, Gordon Reid (Nine Mile) <gordon.r...@ninemilefinancial.com<mailto:gordon.r...@ninemilefinancial.com>>: Hi Denis, Each client runs on a separate user desktop. The client is a C#.NET application which loads ignite in client mode and joins our single java server node running on a remote server. So each client has it’s own JVM running inside ignite .NET. We only have one server node, but many clients. The lock up could be many reasons. 1. User machine has some problem in another application which is starving the client node from resources 2. Client node is running in a debugger and the developer as paused it on a break point 3. There is some bug in our user code which has caused the GUI to block and stop processing events 4. There is a network problem to a single client node Basically we are looking for some type of configuration that is very forgiving when there are problems delivering messages to any of the nodes running in client mode within the desktop GUIs. We are on ignite 2.2.0 Thanks, Gordon. From: Denis Mekhanikov <dmekhani...@gmail.com<mailto:dmekhani...@gmail.com>> Sent: Tuesday, July 31, 2018 10:39 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Cache updates to nodes in client mode Gordon, Does every GUI have its own client Ignite node, or they are shared between applications? Are they running in the same VM, or in separate ones? What do you mean by locking up? Is it related to some Ignite problem? Denis вт, 31 июл. 2018 г. в 9:23, Gordon Reid (Nine Mile) <gordon.r...@ninemilefinancial.com<mailto:gordon.r...@ninemilefinancial.com>>: Hi, We have a single java server instance, and we run multiple .NET nodes (GUIs) in client mode. It seems that when one GUI is locked up (for whatever reason) the other GUIs (client nodes) will stop receiving updates. I.e. it seems that cache sync to client nodes is done on a round robin basis and updates must be acknowledged at each client before the next client is notified. This is very bad for us, as we don’t want an issue on one GUI to affect all other GUIs. Is there someway we can relax the synchronization of updates? Note, GUIs typically have many continuous subscriptions on the various cache entities. This is what I mean by “synchronization”. Thanks, Gordon. This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252 This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252 This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252 This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
