Client Mode and Discovery

[yzhdanov]

Guys,

We are currently finishing working on IGNITE-709 - which will bring client
discovery to Ignite. This mode will allow clients to connect and use the
cluster without taking place in nodes ring and therefore will not introduce
lags to server heartbeats exchange and failure detection. This may be very
critical, as clients may be started on weaker machines.

I want to discuss a configuration question.

Currently we have Ignition.setClientMode() and
IgniteConfiguration.setClientMode(). Setting this to true makes all
configured caches run in client mode. I wanted to extend this behavior and
make discovery switch to client mode, but this is not possible since
TcpDiscoverySpi and ClientDiscoverySpi are different classes with different
configuration. This means that I cannot alter SPI configuraiton, but I need
to create another instance. I don't like the approach. Why do we need
separate SPI class instead of mode in current TCP discovery?

--Yakov

[Vladimir Ozerov]

+1.

On Mon, May 25, 2015 at 6:20 PM, Yakov Zhdanov <[hidden email]> wrote:

> Guys,
>
> We are currently finishing working on IGNITE-709 - which will bring client
> discovery to Ignite. This mode will allow clients to connect and use the
> cluster without taking place in nodes ring and therefore will not introduce
> lags to server heartbeats exchange and failure detection. This may be very
> critical, as clients may be started on weaker machines.
>
> I want to discuss a configuration question.
>
> Currently we have Ignition.setClientMode() and
> IgniteConfiguration.setClientMode(). Setting this to true makes all
> configured caches run in client mode. I wanted to extend this behavior and
> make discovery switch to client mode, but this is not possible since
> TcpDiscoverySpi and ClientDiscoverySpi are different classes with different
> configuration. This means that I cannot alter SPI configuraiton, but I need
> to create another instance. I don't like the approach. Why do we need
> separate SPI class instead of mode in current TCP discovery?
>
> --Yakov
>

[dsetrakyan]

On Mon, May 25, 2015 at 8:20 AM, Yakov Zhdanov <[hidden email]> wrote:

> Why do we need separate SPI class instead of mode in current TCP discovery?
>

I also don't like separate SPI for client-based discovery. Can anyone share
why it is an SPI rather than just a configuration property? Moreover, it
seems like the configuration properties for the client-based and
server-based discovery SPIs will be the same, which makes a separate SPI
even more redundant.

How big of a change is it at this juncture?

D.

[Sergey Evdokimov]

I've merged TcpDiscoverySpi and TcpClientDiscoverySpi, now
only TcpDiscoverySpi is preset.
TcpDiscoverySpi will work in client mode if
IgniteConfiguration.isClientMode == true. If you want to start
TcpDiscoverySpi in server mode regardless of
IgniteConfiguration.isClientMode you can set
TcpDiscoverySpi.setForceServerMode(true)

On Mon, May 25, 2015 at 9:14 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Mon, May 25, 2015 at 8:20 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Why do we need separate SPI class instead of mode in current TCP
> discovery?
> >
>
> I also don't like separate SPI for client-based discovery. Can anyone share
> why it is an SPI rather than just a configuration property? Moreover, it
> seems like the configuration properties for the client-based and
> server-based discovery SPIs will be the same, which makes a separate SPI
> even more redundant.
>
> How big of a change is it at this juncture?
>
> D.
>