Re: Client connect "hangs"
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 Kulichenkowrote: 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 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.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 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 > > > > > > > > > >
Re: Client connect "hangs"
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 Magdawrote: > > > 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 > > > > >
Re: Client connect "hangs"
Yakov, Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-2160 -Val On Mon, Dec 14, 2015 at 1:33 AM, Yakov Zhdanovwrote: > 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 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 > > > > > > > > > >
Re: Client connect "hangs"
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 Setrakyanwrote: 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
Re: Client connect "hangs"
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 Magdawrote: > 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 > > >> 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 >
Re: Client connect "hangs"
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 >
Re: Client connect "hangs"
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 Setrakyanwrote: > 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 > > >