ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin client failover mechanism (+ODBC, JDBC)
Date Thu, 01 Feb 2018 13:55:59 GMT
Ok, let's add simple reconnect logic and see what will come of it.

On Thu, Feb 1, 2018 at 12:49 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> 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 <ptupitsyn@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 <akuznetsov@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 <ptupitsyn@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message