You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by George Wilder <Ge...@sas.com> on 2017/10/20 16:09:36 UTC

locator and peer compatible versions

I have deployed a java application configured as a peer-to-peer Apache Geode v1.1.1 cache.  I also have an Apache Geode v1.1.1 locator.  Both application and locator, when running,  connect to one another with no issue.
I stop both application and locator, then replace the locator with an updated Apache Geode v1.2.1 locator.   When I restart the application(v1.1.1) and the locator(v1.2.1), the locator performs a version check and rejects the connection attempt made by the application:

    INFO     o.a.g.d.i.m.g.Services : received join request from 172.17.0.13(12):32768(version:GEODE 1.1.0)
    WARN  o.a.g.d.i.m.g.Services : detected an attempt to start a peer using an older version of the product 172.17.0.13(12):32768(version:GEODE 1.1.0)
    DEBUG o.a.g.d.i.m.g.Services : sending via JGroups: [JoinResponseMessage(null; ; Rejecting the attempt of a member using an older version of the product to join the distributed system)] recipients: [172.17.0.13(12):32768(version:GEODE 1.1.0)]

Is this expected?


RE: locator and peer compatible versions

Posted by George Wilder <Ge...@sas.com>.
From my perspective, not much, other than no requirement to manage an additional server process.
The benefits of a client/server model have quickly outpaced any prior perceived deployment complexity.


From: Michael Stolz [mailto:mstolz@pivotal.io]
Sent: Friday, October 20, 2017 1:33 PM
To: user@geode.apache.org
Subject: Re: locator and peer compatible versions


EXTERNAL
What benefits are you getting from your application being resident in a peer versus a client?

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771

On Fri, Oct 20, 2017 at 1:00 PM, George Wilder <Ge...@sas.com>> wrote:
Ultimately I'll have more than one peer application.  I was hoping to selectively upgrade different applications, which means for some amount of time (that may include multiple restarts of everything), I'd have a mix of old and new versions of Geode peers in the same deployment.  Sounds like that is not supported and leaves me with two alternatives - upgrade all applications and locators at the same time, or alter the applications to use client/server, as that model appears more lenient in backward compatibility across restarts.



-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io<ma...@pivotal.io>]
Sent: Friday, October 20, 2017 12:21 PM
To: user@geode.apache.org<ma...@geode.apache.org>
Subject: Re: locator and peer compatible versions

It appears that your application attempts to join the cluster as a peer member.  During a rolling upgrade, only peers running an older version are not allowed to join the cluster.  Can you upgrade the application node after restarting the locator with the new geode version?

Anthony

> On Oct 20, 2017, at 9:09 AM, George Wilder <Ge...@sas.com>> wrote:
>
> I have deployed a java application configured as a peer-to-peer Apache Geode v1.1.1 cache.  I also have an Apache Geode v1.1.1 locator.  Both application and locator, when running,  connect to one another with no issue.
> I stop both application and locator, then replace the locator with an updated Apache Geode v1.2.1 locator.   When I restart the application(v1.1.1) and the locator(v1.2.1), the locator performs a version check and rejects the connection attempt made by the application:
>
>    INFO     o.a.g.d.i.m.g.Services : received join request from 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    WARN  o.a.g.d.i.m.g.Services : detected an attempt to start a peer using an older version of the product 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    DEBUG o.a.g.d.i.m.g.Services : sending via JGroups: [JoinResponseMessage(null; ; Rejecting the attempt of a member using an older version of the product to join the distributed system)] recipients: [172.17.0.13(12):32768(version:GEODE 1.1.0)]
>
> Is this expected?
>


Re: locator and peer compatible versions

Posted by Michael Stolz <ms...@pivotal.io>.
What benefits are you getting from your application being resident in a
peer versus a client?

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771

On Fri, Oct 20, 2017 at 1:00 PM, George Wilder <Ge...@sas.com>
wrote:

> Ultimately I'll have more than one peer application.  I was hoping to
> selectively upgrade different applications, which means for some amount of
> time (that may include multiple restarts of everything), I'd have a mix of
> old and new versions of Geode peers in the same deployment.  Sounds like
> that is not supported and leaves me with two alternatives - upgrade all
> applications and locators at the same time, or alter the applications to
> use client/server, as that model appears more lenient in backward
> compatibility across restarts.
>
>
>
> -----Original Message-----
> From: Anthony Baker [mailto:abaker@pivotal.io]
> Sent: Friday, October 20, 2017 12:21 PM
> To: user@geode.apache.org
> Subject: Re: locator and peer compatible versions
>
> It appears that your application attempts to join the cluster as a peer
> member.  During a rolling upgrade, only peers running an older version are
> not allowed to join the cluster.  Can you upgrade the application node
> after restarting the locator with the new geode version?
>
> Anthony
>
> > On Oct 20, 2017, at 9:09 AM, George Wilder <Ge...@sas.com>
> wrote:
> >
> > I have deployed a java application configured as a peer-to-peer Apache
> Geode v1.1.1 cache.  I also have an Apache Geode v1.1.1 locator.  Both
> application and locator, when running,  connect to one another with no
> issue.
> > I stop both application and locator, then replace the locator with an
> updated Apache Geode v1.2.1 locator.   When I restart the
> application(v1.1.1) and the locator(v1.2.1), the locator performs a version
> check and rejects the connection attempt made by the application:
> >
> >    INFO     o.a.g.d.i.m.g.Services : received join request from
> 172.17.0.13(12):32768(version:GEODE 1.1.0)
> >    WARN  o.a.g.d.i.m.g.Services : detected an attempt to start a peer
> using an older version of the product 172.17.0.13(12):32768(version:GEODE
> 1.1.0)
> >    DEBUG o.a.g.d.i.m.g.Services : sending via JGroups:
> [JoinResponseMessage(null; ; Rejecting the attempt of a member using an
> older version of the product to join the distributed system)] recipients:
> [172.17.0.13(12):32768(version:GEODE 1.1.0)]
> >
> > Is this expected?
> >
>
>

RE: locator and peer compatible versions

Posted by George Wilder <Ge...@sas.com>.
Ultimately I'll have more than one peer application.  I was hoping to selectively upgrade different applications, which means for some amount of time (that may include multiple restarts of everything), I'd have a mix of old and new versions of Geode peers in the same deployment.  Sounds like that is not supported and leaves me with two alternatives - upgrade all applications and locators at the same time, or alter the applications to use client/server, as that model appears more lenient in backward compatibility across restarts.



-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io] 
Sent: Friday, October 20, 2017 12:21 PM
To: user@geode.apache.org
Subject: Re: locator and peer compatible versions

It appears that your application attempts to join the cluster as a peer member.  During a rolling upgrade, only peers running an older version are not allowed to join the cluster.  Can you upgrade the application node after restarting the locator with the new geode version?

Anthony

> On Oct 20, 2017, at 9:09 AM, George Wilder <Ge...@sas.com> wrote:
>
> I have deployed a java application configured as a peer-to-peer Apache Geode v1.1.1 cache.  I also have an Apache Geode v1.1.1 locator.  Both application and locator, when running,  connect to one another with no issue.
> I stop both application and locator, then replace the locator with an updated Apache Geode v1.2.1 locator.   When I restart the application(v1.1.1) and the locator(v1.2.1), the locator performs a version check and rejects the connection attempt made by the application:
>
>    INFO     o.a.g.d.i.m.g.Services : received join request from 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    WARN  o.a.g.d.i.m.g.Services : detected an attempt to start a peer using an older version of the product 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    DEBUG o.a.g.d.i.m.g.Services : sending via JGroups: [JoinResponseMessage(null; ; Rejecting the attempt of a member using an older version of the product to join the distributed system)] recipients: [172.17.0.13(12):32768(version:GEODE 1.1.0)]
>
> Is this expected?
>


Re: locator and peer compatible versions

Posted by Anthony Baker <ab...@pivotal.io>.
It appears that your application attempts to join the cluster as a peer member.  During a rolling upgrade, only peers running an older version are not allowed to join the cluster.  Can you upgrade the application node after restarting the locator with the new geode version?

Anthony

> On Oct 20, 2017, at 9:09 AM, George Wilder <Ge...@sas.com> wrote:
> 
> I have deployed a java application configured as a peer-to-peer Apache Geode v1.1.1 cache.  I also have an Apache Geode v1.1.1 locator.  Both application and locator, when running,  connect to one another with no issue.
> I stop both application and locator, then replace the locator with an updated Apache Geode v1.2.1 locator.   When I restart the application(v1.1.1) and the locator(v1.2.1), the locator performs a version check and rejects the connection attempt made by the application:
> 
>    INFO     o.a.g.d.i.m.g.Services : received join request from 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    WARN  o.a.g.d.i.m.g.Services : detected an attempt to start a peer using an older version of the product 172.17.0.13(12):32768(version:GEODE 1.1.0)
>    DEBUG o.a.g.d.i.m.g.Services : sending via JGroups: [JoinResponseMessage(null; ; Rejecting the attempt of a member using an older version of the product to join the distributed system)] recipients: [172.17.0.13(12):32768(version:GEODE 1.1.0)]
> 
> Is this expected?
>