Great, thanks! Is listening for that the way you would implement what I am trying to do?
Ralph > On Apr 25, 2016, at 4:22 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > > Ralph, > > EVT_NODE_LEFT and EVT_NODE_FAILED occur on local node. They essentially mean > "I saw that remote node went down". > > Vladimir. > >> On Sat, Apr 23, 2016 at 5:48 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> Some more information that may be of help. >> >> Each user of a client application creates a “session” that is represented in >> the distributed cache. Each session has its own connection to the third >> party application. If a user uses multiple client applications they will >> reuse the same session and connection with the third party application. So >> when a single node goes down all the user’s sessions need to become “owned” >> by different nodes. >> >> In the javadoc I do see IgniteEvents.localListen(), but the description says >> it listens for “local” events. I wouldn’t expect EVT_NODE_LEFT or >> EVT_NODE_FAILED to be considered local events, so I am a bit confused as to >> what the method does. >> >> Ralph >> >>> On Apr 23, 2016, at 6:49 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>> From what I understand in the documentation client mode will mean I will >>> lose high availability, which is the point of using a distributed cache. >>> >>> The architecture is such that we have multiple client applications that >>> need to communicate with the service that has the clustered cache. The >>> client applications expect to get callbacks when events occur in the third >>> party application the service is communicating with. If one of the service >>> nodes fail - for example during a rolling deployment - we need one of the >>> other nodes to re-establish the connection with the third party so it can >>> continue to monitor for the events. Note that the service servers are >>> load-balanced so they may each have an arbitrary number of connections with >>> the third party. >>> >>> So I either need a listener that tells me when one of the nodes in the >>> cluster has left or a way of creating the connection using something ignite >>> provides so that it automatically causes the connection to be recreated >>> when a node leaves. >>> >>> Ralph >>> >>> >>>> On Apr 23, 2016, at 12:01 AM, Владислав Пятков <vldpyat...@gmail.com> >>>> wrote: >>>> >>>> Hello Ralph, >>>> >>>> I think the correct way is to use client node (with setClientMode - true) >>>> for control of cluster. Client node is isolated from data processing and >>>> not subject fail of load. >>>> Why are you connect each node with third party application instead of to >>>> do that only from client? >>>> >>>>> On Sat, Apr 23, 2016 at 4:10 AM, Ralph Goers <ralph.go...@dslextreme.com> >>>>> wrote: >>>>> I have an application that is using Ignite for a clustered cache. Each >>>>> member of the cache will have connections open with a third party >>>>> application. When a cluster member stops its connections must be >>>>> re-established on other cluster members. >>>>> >>>>> I can do this manually if I have a way of detecting a node has left the >>>>> cluster, but I am hoping that there is some other recommended way of >>>>> handling this. >>>>> >>>>> Any suggestions? >>>>> >>>>> Ralph >>>> >>>> >>>> >>>> -- >>>> Vladislav Pyatkov >>> >> >
