Pavel, I disagree. I think automatic reconnect is a very useful feature. For example, all client-side operation can throw exception anyway, so if you throw an exception due to a client reconnect, it will not require any additional exception-handling logic.
On the other hand, after a few failed operations in case of a reconnect, the client will continue to operate normally. This will make our clients resilient to failures and make it way more powerful. I strongly vote to add this behavior. D. On Wed, Jan 31, 2018 at 3:15 AM, 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 > > >
