I am ok with the suggestion. Val, can you please file a ticket (or I guess we already should have one) and put your suggestion to it.
--Yakov 2015-12-14 11:47 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Denis, > > Yes, this can be a workaround, but at the same time it makes things even > more confusing :) This means that client node behavior depends on > some property on discovery SPI, while this property should influence only > internals of discovery protocol. > > I think the client should always work in the same way: start without > blocking and then throw disconnect exception if there are no > servers. Currently this behavior depends on presence of server nodes, > forceServerMode flag and probably smth else, which makes it unpredictable. > > -Val > > On Monday, December 14, 2015, Denis Magda <dma...@gridgain.com> wrote: > > > Guys, > > > > There is already a configuration property that lets to complete client's > > launching procedure even if there is no any server node in a cluster - > > TcpDiscoverySpi.setForceServerMode. > > The only side effect of this property is that a client node will become a > > part of the ring. > > > > Is this property applicable or you want to support something different? > > > > -- > > Denis > > > > On 12/12/2015 6:13 AM, Valentin Kulichenko wrote: > > > >> Dmitry, > >> > >> How do you think, should we just change the behavior or make it > >> configurable? > >> > >> -Val > >> > >> On Fri, Dec 11, 2015 at 1:59 PM, Dmitriy Setrakyan < > dsetrak...@apache.org > >> > > >> wrote: > >> > >> I agree that we have a consistency issue here. I am OK with the change. > >>> > >>> On Fri, Dec 11, 2015 at 11:43 AM, Valentin Kulichenko < > >>> valentin.kuliche...@gmail.com> wrote: > >>> > >>> Folks, > >>>> > >>>> Currently there are two different ways how a client node behaves in > case > >>>> there are no server nodes: > >>>> > >>>> 1. If it's trying to start, it will wait and block the thread that > >>>> called Ignition.start(). > >>>> 2. If server nodes left when it was already running, it will throw > >>>> disconnect exception on any API call. > >>>> > >>>> It seems confusing to me (and not only to me, as far as I can see from > >>>> > >>> the > >>> > >>>> users' feedback). First of all, it's just inconsistent and requires > >>>> different processing for these different cases. Second of all, p.1 is > >>>> > >>> often > >>> > >>>> treated as a hang, but not as correct behavior. And it's getting worse > >>>> > >>> when > >>> > >>>> the node is started as a part of web application, because it blocks > the > >>>> application startup process. > >>>> > >>>> I think we should start a client node (or at least have a configurable > >>>> option) even if there are no servers yet. Until the first server > joins, > >>>> > >>> it > >>> > >>>> will just throw disconnect exceptions. > >>>> > >>>> Thoughts? > >>>> > >>>> -Val > >>>> > >>>> > > >
