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) < [email protected]>: > 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 <[email protected]> > *Sent:* Wednesday, August 1, 2018 10:28 PM > > > *To:* [email protected] > *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) < > [email protected]>: > > 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 <[email protected]> > *Sent:* Tuesday, July 31, 2018 10:39 PM > *To:* [email protected] > *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) < > [email protected]>: > > 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 >
