You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Valentin Kulichenko <va...@gmail.com> on 2015/12/11 20:43:36 UTC
Client connect "hangs"
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
Re: Client connect "hangs"
Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.
There is topology-join timeout in the client logic, which is set to 0 by default. This will block until topology join is successful.
Changing the default value to several seconds will give a clear notion to the user about this blockUntilConnectedOrTimedOut logic, and will give a possibility to catch and retry.
Although, it might not be a complete solution to what Valentin is addressing, I think it's worth to have a look at it too.
-Roman
On Tuesday, December 15, 2015 6:26 AM, Valentin Kulichenko <va...@gmail.com> wrote:
Yakov,
Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-2160
-Val
On Mon, Dec 14, 2015 at 1:33 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> 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.kulichenko@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 <dm...@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 <
> > dsetrakyan@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.kulichenko@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
> > >>>>
> > >>>>
> > >
> >
>
Re: Client connect "hangs"
Posted by Valentin Kulichenko <va...@gmail.com>.
Yakov,
Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-2160
-Val
On Mon, Dec 14, 2015 at 1:33 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> 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.kulichenko@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 <dm...@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 <
> > dsetrakyan@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.kulichenko@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
> > >>>>
> > >>>>
> > >
> >
>
Re: Client connect "hangs"
Posted by Yakov Zhdanov <yz...@apache.org>.
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.kulichenko@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 <dm...@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 <
> dsetrakyan@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.kulichenko@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
> >>>>
> >>>>
> >
>
Re: Client connect "hangs"
Posted by Valentin Kulichenko <va...@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 <dm...@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 <dsetrakyan@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.kulichenko@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
>>>>
>>>>
>
Re: Client connect "hangs"
Posted by Denis Magda <dm...@gridgain.com>.
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 <ds...@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.kulichenko@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
>>>
Re: Client connect "hangs"
Posted by Valentin Kulichenko <va...@gmail.com>.
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 <ds...@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.kulichenko@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
> >
>
Re: Client connect "hangs"
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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.kulichenko@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
>