Alexey, retrieving addresses from topology makes sense, but in this thread I'm trying to understand whether any kind of built-in failover makes sense at all at the Ignite API level.
I mean, on the business logic level failover certainly makes sense: if Web Agent has failed to execute some operation, it can show an error, automatically reconnect to another node and continue working. But on the Ignite API level it gets questionable. We can implement some failover/reconnect logic, but users still has to handle failed operations themselves. Pavel On Wed, Jan 31, 2018 at 2:08 PM, Alexey Kuznetsov <akuznet...@apache.org> wrote: > Pavel, > > I hope, that at some point Web agent (connector to Web Console) will be > refactored from REST to thin client. > > It will be nice if thin client will support following modes: > 1) Specify several addresses in thin client connection config. Thin client > will use ONLY this addresses (hardcoded list). > 2) Same as #1, but in addition to specified list of addresses thin client > collect list of "connectable" nodes from topology (extendable list). > > What do you think? > > > On Wed, Jan 31, 2018 at 5:14 PM, Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > Igniters, > > > > I'm working on client-side failover logic for .NET Thin Client. > > This will probably apply to ODBC and JDBC thin clients as well in future. > > > > Currently all thin clients connect to a single specified Ignite node. > > The idea is to have multiple known nodes (host:port pairs) and reconnect > > to another node if current one goes down. > > > > Problems: > > - Protocol is stateful, server keeps track of query cursors for the > session > > - Many operations are not idempotent, so retry is not an option > > - Async operations and multithreading are supported in .NET thin client > > > > So while we can detect socket connection failure and reconnect to a > > different node, > > all currently executing client operations and query cursors will still > fail > > with an exception. > > > > I'm not sure how useful this behavior will be. > > Any thoughts, ideas? > > > > Thanks, > > Pavel > > > > > > -- > Alexey Kuznetsov >
