Well, I agree with Pavel here. To me looks like this feature gives a little to a user, as they need to write all the same amount of code as they would need to if there was no this feature. It also will produce some new issues with the "hanging" of operations, while thin client tries and fails to re-connect to several nodes.
On the other hand, the second approach suggested by Alexey makes more sense to me. In general case, user does not have a list of all nodes in the cluster, so reconnection to the "next alive" node could be useful in some cases. Best Regards, Igor On Wed, Jan 31, 2018 at 2:15 PM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > 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 > > >
