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
>

Reply via email to