Re: 2 minute gateway startup time due to GEODE-5591
Yes. The current fix is to let each gateway receiver (in hydra tests,
there're a lot) to compete port 5500. Only one member will win, all other
members will timeout after 2 minutes. Then they keep compete for port 5501.
Again, only one member will win.
In that case, if there are 5 receivers, it will take 10 minutes to start
all the receivers.
So I enhanced the current fix (see the diff attached) to let each receiver
to pick a random port to start, if any one failed, only this guy will try
currPort++. If reached endPort, continue on startPort, until reached his
random port again.
To enhance the 2-minute-timeout is definitely another issue.
Regards
Gester
On Tue, Sep 4, 2018 at 4:38 PM, Dan Smith wrote:
> Spitting this into a separate thread.
>
> I see the issue. The two minute timeout is the constructor for
> AcceptorImpl, where it retries to bind for 2 minutes.
>
> That behavior makes sense for CacheServer.start.
>
> But it doesn't make sense for the new logic in GatewayReceiver.start() from
> GEODE-5591. That code is trying to use CacheServer.start to scan for an
> available port, trying each port in a range. That free port finding logic
> really doesn't want to have two minutes of retries for each port. It seems
> like we need to rework the fix for GEODE-5591.
>
> Does it make sense to hold up the release to rework this fix, or should we
> just revert it? Have we switched concourse over to using alpine linux,
> which I think was the original motivation for this fix?
>
> -Dan
>
> On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote:
>
> > Why is it waiting at all in this case? Where is this 2 minute timeout
> > coming from?
> >
> > -Dan
> >
> > On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > > wrote:
> >
> >> So the issue is that it takes longer to start than previous releases?
> >> Also, is this wait time only when using Gfsh to create gateway-receiver?
> >>
> >> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote:
> >>
> >> > Currently we have a minor issue in the release branch as pointed out
> by
> >> > Barry O.
> >> > We will wait till a resolution is figured out for this issue.
> >> >
> >> > Steps:
> >> > 1. create locator
> >> > 2. start server --name=server1 --server-port=40404
> >> > 3. start server --name=server2 --server-port=40405
> >> > 4. create gateway-receiver --member=server1
> >> > 5. create gateway-receiver --member=server2 `This gets stuck for 2
> >> minutes`
> >> >
> >> > Is the 2 minute wait time acceptable? Should we document it? When we
> >> revert
> >> > GEODE-5591, this issue does not happen.
> >> >
> >> > Regards
> >> > Nabarun Nag
> >> >
> >>
> >
>
diff --git
a/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/WANTestBase.java
b/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/WANTestBase.java
index a09194209..e13e7ec78 100644
---
a/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/WANTestBase.java
+++
b/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/WANTestBase.java
@@ -2020,7 +2020,7 @@ public class WANTestBase extends DistributedTestCase {
GatewayReceiver receiver = fact.create();
assertThatThrownBy(receiver::start)
.isInstanceOf(GatewayReceiverException.class)
-.hasMessageContaining("No available free port found in the given
range");
+.hasMessageContaining("Failed to create server socket on");
}
public static int createReceiverWithSSL(int locPort) {
diff --git
a/geode-wan/src/integrationTest/java/org/apache/geode/internal/cache/wan/misc/WANConfigurationJUnitTest.java
b/geode-wan/src/integrationTest/java/org/apache/geode/internal/cache/wan/misc/WANConfigurationJUnitTest.java
index 038b759ae..ccd9503e6 100644
---
a/geode-wan/src/integrationTest/java/org/apache/geode/internal/cache/wan/misc/WANConfigurationJUnitTest.java
+++
b/geode-wan/src/integrationTest/java/org/apache/geode/internal/cache/wan/misc/WANConfigurationJUnitTest.java
@@ -448,7 +448,8 @@ public class WANConfigurationJUnitTest {
GatewayReceiver receiver = fact.create();
-assertThatThrownBy(() ->
receiver.start()).isInstanceOf(GatewayReceiverException.class);
+assertThatThrownBy(() ->
receiver.start()).isInstanceOf(GatewayReceiverException.class)
+.hasMessageContaining("Failed to create server socket on");
}
@Test
diff --git
a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewayReceiverImpl.java
b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewayReceiverImpl.java
index cd2702991..786b354a4 100644
---
a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewayReceiverImpl.java
+++
b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewayReceiverImpl.java
@@ -26,6 +26,7 @@ import org.apache.geode.cache.wan.GatewayReceiver;
import org.apache.geode.cache.wan.GatewayTransportFilter;
import org.apache.geode.distributed.internal.InternalDistributedSyste
Re: 2 minute gateway startup time due to GEODE-5591
Revert it on the release branch and fix it on develop. > On Sep 4, 2018, at 5:13 PM, Sean Goller wrote: > > It affects us on any linux platform that doesn't use glibc. It's not worth > holding up the release for. It's been this way for 20 years, right? ;) > > Revert it. > >> On Tue, Sep 4, 2018 at 5:09 PM Udo Kohlmeyer wrote: >> >> Imo (and I'm coming in cold)... We are NOT officially supporting Alpine >> linux (yet), which is the basis for this ticket, maybe push this to a >> later release? >> >> I prefer us getting out the fixes we have and release a more optimal >> version of GEODE-5591 later. >> >> IF this is a bug that will affect us on EVERY linux distro, then we >> should fix, otherwise, I vote to push it to 1.8 >> >> --Udo >> >> >>> On 9/4/18 16:38, Dan Smith wrote: >>> Spitting this into a separate thread. >>> >>> I see the issue. The two minute timeout is the constructor for >>> AcceptorImpl, where it retries to bind for 2 minutes. >>> >>> That behavior makes sense for CacheServer.start. >>> >>> But it doesn't make sense for the new logic in GatewayReceiver.start() >> from >>> GEODE-5591. That code is trying to use CacheServer.start to scan for an >>> available port, trying each port in a range. That free port finding logic >>> really doesn't want to have two minutes of retries for each port. It >> seems >>> like we need to rework the fix for GEODE-5591. >>> >>> Does it make sense to hold up the release to rework this fix, or should >> we >>> just revert it? Have we switched concourse over to using alpine linux, >>> which I think was the original motivation for this fix? >>> >>> -Dan >>> On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: Why is it waiting at all in this case? Where is this 2 minute timeout coming from? -Dan On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda < >> sai.boorlaga...@gmail.com > wrote: > So the issue is that it takes longer to start than previous releases? > Also, is this wait time only when using Gfsh to create >> gateway-receiver? > >> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: >> >> Currently we have a minor issue in the release branch as pointed out >> by >> Barry O. >> We will wait till a resolution is figured out for this issue. >> >> Steps: >> 1. create locator >> 2. start server --name=server1 --server-port=40404 >> 3. start server --name=server2 --server-port=40405 >> 4. create gateway-receiver --member=server1 >> 5. create gateway-receiver --member=server2 `This gets stuck for 2 > minutes` >> Is the 2 minute wait time acceptable? Should we document it? When we > revert >> GEODE-5591, this issue does not happen. >> >> Regards >> Nabarun Nag >> >> >>
Re: 2 minute gateway startup time due to GEODE-5591
We should fix this for the release. -Anil. On Tue, Sep 4, 2018 at 5:09 PM Udo Kohlmeyer wrote: > Imo (and I'm coming in cold)... We are NOT officially supporting Alpine > linux (yet), which is the basis for this ticket, maybe push this to a > later release? > > I prefer us getting out the fixes we have and release a more optimal > version of GEODE-5591 later. > > IF this is a bug that will affect us on EVERY linux distro, then we > should fix, otherwise, I vote to push it to 1.8 > > --Udo > > > On 9/4/18 16:38, Dan Smith wrote: > > Spitting this into a separate thread. > > > > I see the issue. The two minute timeout is the constructor for > > AcceptorImpl, where it retries to bind for 2 minutes. > > > > That behavior makes sense for CacheServer.start. > > > > But it doesn't make sense for the new logic in GatewayReceiver.start() > from > > GEODE-5591. That code is trying to use CacheServer.start to scan for an > > available port, trying each port in a range. That free port finding logic > > really doesn't want to have two minutes of retries for each port. It > seems > > like we need to rework the fix for GEODE-5591. > > > > Does it make sense to hold up the release to rework this fix, or should > we > > just revert it? Have we switched concourse over to using alpine linux, > > which I think was the original motivation for this fix? > > > > -Dan > > > > On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: > > > >> Why is it waiting at all in this case? Where is this 2 minute timeout > >> coming from? > >> > >> -Dan > >> > >> On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > >>> wrote: > >>> So the issue is that it takes longer to start than previous releases? > >>> Also, is this wait time only when using Gfsh to create > gateway-receiver? > >>> > >>> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > >>> > Currently we have a minor issue in the release branch as pointed out > by > Barry O. > We will wait till a resolution is figured out for this issue. > > Steps: > 1. create locator > 2. start server --name=server1 --server-port=40404 > 3. start server --name=server2 --server-port=40405 > 4. create gateway-receiver --member=server1 > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > >>> minutes` > Is the 2 minute wait time acceptable? Should we document it? When we > >>> revert > GEODE-5591, this issue does not happen. > > Regards > Nabarun Nag > > >
Re: 2 minute gateway startup time due to GEODE-5591
It affects us on any linux platform that doesn't use glibc. It's not worth holding up the release for. It's been this way for 20 years, right? ;) Revert it. On Tue, Sep 4, 2018 at 5:09 PM Udo Kohlmeyer wrote: > Imo (and I'm coming in cold)... We are NOT officially supporting Alpine > linux (yet), which is the basis for this ticket, maybe push this to a > later release? > > I prefer us getting out the fixes we have and release a more optimal > version of GEODE-5591 later. > > IF this is a bug that will affect us on EVERY linux distro, then we > should fix, otherwise, I vote to push it to 1.8 > > --Udo > > > On 9/4/18 16:38, Dan Smith wrote: > > Spitting this into a separate thread. > > > > I see the issue. The two minute timeout is the constructor for > > AcceptorImpl, where it retries to bind for 2 minutes. > > > > That behavior makes sense for CacheServer.start. > > > > But it doesn't make sense for the new logic in GatewayReceiver.start() > from > > GEODE-5591. That code is trying to use CacheServer.start to scan for an > > available port, trying each port in a range. That free port finding logic > > really doesn't want to have two minutes of retries for each port. It > seems > > like we need to rework the fix for GEODE-5591. > > > > Does it make sense to hold up the release to rework this fix, or should > we > > just revert it? Have we switched concourse over to using alpine linux, > > which I think was the original motivation for this fix? > > > > -Dan > > > > On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: > > > >> Why is it waiting at all in this case? Where is this 2 minute timeout > >> coming from? > >> > >> -Dan > >> > >> On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > >>> wrote: > >>> So the issue is that it takes longer to start than previous releases? > >>> Also, is this wait time only when using Gfsh to create > gateway-receiver? > >>> > >>> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > >>> > Currently we have a minor issue in the release branch as pointed out > by > Barry O. > We will wait till a resolution is figured out for this issue. > > Steps: > 1. create locator > 2. start server --name=server1 --server-port=40404 > 3. start server --name=server2 --server-port=40405 > 4. create gateway-receiver --member=server1 > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > >>> minutes` > Is the 2 minute wait time acceptable? Should we document it? When we > >>> revert > GEODE-5591, this issue does not happen. > > Regards > Nabarun Nag > > >
Re: 2 minute gateway startup time due to GEODE-5591
Imo (and I'm coming in cold)... We are NOT officially supporting Alpine linux (yet), which is the basis for this ticket, maybe push this to a later release? I prefer us getting out the fixes we have and release a more optimal version of GEODE-5591 later. IF this is a bug that will affect us on EVERY linux distro, then we should fix, otherwise, I vote to push it to 1.8 --Udo On 9/4/18 16:38, Dan Smith wrote: Spitting this into a separate thread. I see the issue. The two minute timeout is the constructor for AcceptorImpl, where it retries to bind for 2 minutes. That behavior makes sense for CacheServer.start. But it doesn't make sense for the new logic in GatewayReceiver.start() from GEODE-5591. That code is trying to use CacheServer.start to scan for an available port, trying each port in a range. That free port finding logic really doesn't want to have two minutes of retries for each port. It seems like we need to rework the fix for GEODE-5591. Does it make sense to hold up the release to rework this fix, or should we just revert it? Have we switched concourse over to using alpine linux, which I think was the original motivation for this fix? -Dan On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: Why is it waiting at all in this case? Where is this 2 minute timeout coming from? -Dan On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda wrote: So the issue is that it takes longer to start than previous releases? Also, is this wait time only when using Gfsh to create gateway-receiver? On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: Currently we have a minor issue in the release branch as pointed out by Barry O. We will wait till a resolution is figured out for this issue. Steps: 1. create locator 2. start server --name=server1 --server-port=40404 3. start server --name=server2 --server-port=40405 4. create gateway-receiver --member=server1 5. create gateway-receiver --member=server2 `This gets stuck for 2 minutes` Is the 2 minute wait time acceptable? Should we document it? When we revert GEODE-5591, this issue does not happen. Regards Nabarun Nag
Re: 2 minute gateway startup time due to GEODE-5591
If it's to get the release out, I'm fine with reverting. I don't like it, but I'm not willing to die on that hill. :) -S. On Tue, Sep 4, 2018 at 4:38 PM Dan Smith wrote: > Spitting this into a separate thread. > > I see the issue. The two minute timeout is the constructor for > AcceptorImpl, where it retries to bind for 2 minutes. > > That behavior makes sense for CacheServer.start. > > But it doesn't make sense for the new logic in GatewayReceiver.start() from > GEODE-5591. That code is trying to use CacheServer.start to scan for an > available port, trying each port in a range. That free port finding logic > really doesn't want to have two minutes of retries for each port. It seems > like we need to rework the fix for GEODE-5591. > > Does it make sense to hold up the release to rework this fix, or should we > just revert it? Have we switched concourse over to using alpine linux, > which I think was the original motivation for this fix? > > -Dan > > On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: > > > Why is it waiting at all in this case? Where is this 2 minute timeout > > coming from? > > > > -Dan > > > > On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > > > wrote: > > > >> So the issue is that it takes longer to start than previous releases? > >> Also, is this wait time only when using Gfsh to create gateway-receiver? > >> > >> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > >> > >> > Currently we have a minor issue in the release branch as pointed out > by > >> > Barry O. > >> > We will wait till a resolution is figured out for this issue. > >> > > >> > Steps: > >> > 1. create locator > >> > 2. start server --name=server1 --server-port=40404 > >> > 3. start server --name=server2 --server-port=40405 > >> > 4. create gateway-receiver --member=server1 > >> > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > >> minutes` > >> > > >> > Is the 2 minute wait time acceptable? Should we document it? When we > >> revert > >> > GEODE-5591, this issue does not happen. > >> > > >> > Regards > >> > Nabarun Nag > >> > > >> > > >
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
So the issue is that it takes longer to start than previous releases? Yes Also, is this wait time only when using Gfsh to create gateway-receiver? No, even APIs On Tue, Sep 4, 2018 at 4:43 PM Anilkumar Gingade wrote: > Its not gfsh specific. Its in the Gateway receiver start. > > It looks like the changes with GEODE-5591 still hit the earlier issue (it > was fixing) if the port is same as the port returned by "getPortToStart()", > that was removed. I may be wrong. > > -Anil. > > > On Tue, Sep 4, 2018 at 4:39 PM Sai Boorlagadda > wrote: > > > So the issue is that it takes longer to start than previous releases? > > Also, is this wait time only when using Gfsh to create gateway-receiver? > > > > On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > > > > > Currently we have a minor issue in the release branch as pointed out by > > > Barry O. > > > We will wait till a resolution is figured out for this issue. > > > > > > Steps: > > > 1. create locator > > > 2. start server --name=server1 --server-port=40404 > > > 3. start server --name=server2 --server-port=40405 > > > 4. create gateway-receiver --member=server1 > > > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > > minutes` > > > > > > Is the 2 minute wait time acceptable? Should we document it? When we > > revert > > > GEODE-5591, this issue does not happen. > > > > > > Regards > > > Nabarun Nag > > > > > > On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > > > > > > > Status Update on release process for 1.7.0 > > > > - checkPom files are being modified to have version as 1.7.0 instead > of > > > > 1.8.0-SNAPSHOT > > > > - gradle.properties file has been modified to reflect 1.7.0 as the > > > version. > > > > - Version.java has been reverted to remove all changes corresponding > to > > > > 1.8.0 > > > > - CommandInitializer.java has been reverted to remove changes for > 1.8.0 > > > > - LuceneIndexCommandsJUnitTest.java has been modified to change > > > > Version.GEODE_180 to GEODE_170 > > > > - LuceneIndexCommands.java has been modified to change > > Version.GEODE_180 > > > > to GEODE_170 > > > > -TXCommitMessage.java has been modified to change Version.GEODE_180 > to > > > > GEODE_170 > > > > > > > > I will be getting in touch with the individual developers to verify > my > > > > changes. > > > > The branch will be update once we get a green light on these changes. > > > > > > > > Still need updates on these tickets: > > > > > > > > GEODE-5600 - [Patrick Rhomberg] > > > > GEODE-5578 - [Robert Houghton] > > > > GEODE-5492 - [Robert Houghton] > > > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > > > > > > These tickets have commits into develop but they are still open with > > fix > > > > version as 1.8.0 > > > > > > > > Regards > > > > Nabarun Nag > > > > > > > > > > > > > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery > wrote: > > > > > > > >> I have resolved GEODE-5254 > > > >> > > > >> Dale > > > >> > > > >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > > > >> > > > > >> > Requesting status update on the following JIRA tickets. These > > tickets > > > >> have > > > >> > commits into develop against its name but the status is still > open / > > > >> > unresolved. > > > >> > > > > >> > GEODE-5600 - [Patrick Rhomberg] > > > >> > GEODE-5578 - [Robert Houghton] > > > >> > GEODE-5492 - [Robert Houghton] > > > >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > >> > GEODE-5254 - [Dale Emery] > > > >> > > > > >> > GEODE-4794 - [Sai] > > > >> > GEODE-5594 - [Sai] > > > >> > > > > >> > Regards > > > >> > Nabarun Nag > > > >> > > > > >> > > > > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag > > wrote: > > > >> > > > > >> >> > > > >> >> Please continue using 1.7.0 as a fix version in JIRA till the > email > > > >> comes > > > >> >> in that the 1.7.0 release branch has be cut. > > > >> >> > > > >> >> Changing the fixed version for the following tickets to 1.7.0 > from > > > >> 1.8.0 > > > >> >> as these fixes will be included in the 1.7.0 release > > > >> >> > > > >> >> GEODE-5671 > > > >> >> GEODE-5662 > > > >> >> GEODE-5660 > > > >> >> GEODE-5652 > > > >> >> > > > >> >> Regards > > > >> >> Nabarun Nag > > > >> >> > > > >> >> > > > >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag > > wrote: > > > >> >> > > > >> >>> A new feature of get/set cluster config was added as new feature > > to > > > >> gfsh. > > > >> >>> This needs to be added to the documentation. > > > >> >>> Once this is done, the branch will be ready. > > > >> >>> > > > >> >>> Regards > > > >> >>> Nabarun > > > >> >>> > > > >> >>> > > > >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < > > > >> amurm...@pivotal.io> > > > >> >>> wrote: > > > >> >>> > > > >> Nabarun, do you still see anything blocking cutting the release > > at > > > >> this > > > >> point? > > > >> > > > >> Maybe we can even get a pipeline going today? 😳 > > > >> > > > >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > > > >>
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
Its not gfsh specific. Its in the Gateway receiver start. It looks like the changes with GEODE-5591 still hit the earlier issue (it was fixing) if the port is same as the port returned by "getPortToStart()", that was removed. I may be wrong. -Anil. On Tue, Sep 4, 2018 at 4:39 PM Sai Boorlagadda wrote: > So the issue is that it takes longer to start than previous releases? > Also, is this wait time only when using Gfsh to create gateway-receiver? > > On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > > > Currently we have a minor issue in the release branch as pointed out by > > Barry O. > > We will wait till a resolution is figured out for this issue. > > > > Steps: > > 1. create locator > > 2. start server --name=server1 --server-port=40404 > > 3. start server --name=server2 --server-port=40405 > > 4. create gateway-receiver --member=server1 > > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > minutes` > > > > Is the 2 minute wait time acceptable? Should we document it? When we > revert > > GEODE-5591, this issue does not happen. > > > > Regards > > Nabarun Nag > > > > On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > > > > > Status Update on release process for 1.7.0 > > > - checkPom files are being modified to have version as 1.7.0 instead of > > > 1.8.0-SNAPSHOT > > > - gradle.properties file has been modified to reflect 1.7.0 as the > > version. > > > - Version.java has been reverted to remove all changes corresponding to > > > 1.8.0 > > > - CommandInitializer.java has been reverted to remove changes for 1.8.0 > > > - LuceneIndexCommandsJUnitTest.java has been modified to change > > > Version.GEODE_180 to GEODE_170 > > > - LuceneIndexCommands.java has been modified to change > Version.GEODE_180 > > > to GEODE_170 > > > -TXCommitMessage.java has been modified to change Version.GEODE_180 to > > > GEODE_170 > > > > > > I will be getting in touch with the individual developers to verify my > > > changes. > > > The branch will be update once we get a green light on these changes. > > > > > > Still need updates on these tickets: > > > > > > GEODE-5600 - [Patrick Rhomberg] > > > GEODE-5578 - [Robert Houghton] > > > GEODE-5492 - [Robert Houghton] > > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > > > > These tickets have commits into develop but they are still open with > fix > > > version as 1.8.0 > > > > > > Regards > > > Nabarun Nag > > > > > > > > > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > > > > > >> I have resolved GEODE-5254 > > >> > > >> Dale > > >> > > >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > > >> > > > >> > Requesting status update on the following JIRA tickets. These > tickets > > >> have > > >> > commits into develop against its name but the status is still open / > > >> > unresolved. > > >> > > > >> > GEODE-5600 - [Patrick Rhomberg] > > >> > GEODE-5578 - [Robert Houghton] > > >> > GEODE-5492 - [Robert Houghton] > > >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > >> > GEODE-5254 - [Dale Emery] > > >> > > > >> > GEODE-4794 - [Sai] > > >> > GEODE-5594 - [Sai] > > >> > > > >> > Regards > > >> > Nabarun Nag > > >> > > > >> > > > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag > wrote: > > >> > > > >> >> > > >> >> Please continue using 1.7.0 as a fix version in JIRA till the email > > >> comes > > >> >> in that the 1.7.0 release branch has be cut. > > >> >> > > >> >> Changing the fixed version for the following tickets to 1.7.0 from > > >> 1.8.0 > > >> >> as these fixes will be included in the 1.7.0 release > > >> >> > > >> >> GEODE-5671 > > >> >> GEODE-5662 > > >> >> GEODE-5660 > > >> >> GEODE-5652 > > >> >> > > >> >> Regards > > >> >> Nabarun Nag > > >> >> > > >> >> > > >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag > wrote: > > >> >> > > >> >>> A new feature of get/set cluster config was added as new feature > to > > >> gfsh. > > >> >>> This needs to be added to the documentation. > > >> >>> Once this is done, the branch will be ready. > > >> >>> > > >> >>> Regards > > >> >>> Nabarun > > >> >>> > > >> >>> > > >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < > > >> amurm...@pivotal.io> > > >> >>> wrote: > > >> >>> > > >> Nabarun, do you still see anything blocking cutting the release > at > > >> this > > >> point? > > >> > > >> Maybe we can even get a pipeline going today? 😳 > > >> > > >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > > >> sai.boorlaga...@gmail.com > > >> > wrote: > > >> > > >> > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have > > the > > >> code > > >> > ready. > > >> > > > >> > GEODE-5594, adds a new flag to enable hostname validation and is > > >> disabled > > >> > by default so we are good with changes that are already merged > and > > >> > documentation for GEODE-5594 is ready merged. > > >> > > > >> > Naba, after the branch is cut we should delete windows jobs from > > the > > >
2 minute gateway startup time due to GEODE-5591
Spitting this into a separate thread. I see the issue. The two minute timeout is the constructor for AcceptorImpl, where it retries to bind for 2 minutes. That behavior makes sense for CacheServer.start. But it doesn't make sense for the new logic in GatewayReceiver.start() from GEODE-5591. That code is trying to use CacheServer.start to scan for an available port, trying each port in a range. That free port finding logic really doesn't want to have two minutes of retries for each port. It seems like we need to rework the fix for GEODE-5591. Does it make sense to hold up the release to rework this fix, or should we just revert it? Have we switched concourse over to using alpine linux, which I think was the original motivation for this fix? -Dan On Tue, Sep 4, 2018 at 4:25 PM, Dan Smith wrote: > Why is it waiting at all in this case? Where is this 2 minute timeout > coming from? > > -Dan > > On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda > wrote: > >> So the issue is that it takes longer to start than previous releases? >> Also, is this wait time only when using Gfsh to create gateway-receiver? >> >> On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: >> >> > Currently we have a minor issue in the release branch as pointed out by >> > Barry O. >> > We will wait till a resolution is figured out for this issue. >> > >> > Steps: >> > 1. create locator >> > 2. start server --name=server1 --server-port=40404 >> > 3. start server --name=server2 --server-port=40405 >> > 4. create gateway-receiver --member=server1 >> > 5. create gateway-receiver --member=server2 `This gets stuck for 2 >> minutes` >> > >> > Is the 2 minute wait time acceptable? Should we document it? When we >> revert >> > GEODE-5591, this issue does not happen. >> > >> > Regards >> > Nabarun Nag >> > >> >
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
Why is it waiting at all in this case? Where is this 2 minute timeout coming from? -Dan On Tue, Sep 4, 2018 at 4:12 PM, Sai Boorlagadda wrote: > So the issue is that it takes longer to start than previous releases? > Also, is this wait time only when using Gfsh to create gateway-receiver? > > On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > > > Currently we have a minor issue in the release branch as pointed out by > > Barry O. > > We will wait till a resolution is figured out for this issue. > > > > Steps: > > 1. create locator > > 2. start server --name=server1 --server-port=40404 > > 3. start server --name=server2 --server-port=40405 > > 4. create gateway-receiver --member=server1 > > 5. create gateway-receiver --member=server2 `This gets stuck for 2 > minutes` > > > > Is the 2 minute wait time acceptable? Should we document it? When we > revert > > GEODE-5591, this issue does not happen. > > > > Regards > > Nabarun Nag > > > > On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > > > > > Status Update on release process for 1.7.0 > > > - checkPom files are being modified to have version as 1.7.0 instead of > > > 1.8.0-SNAPSHOT > > > - gradle.properties file has been modified to reflect 1.7.0 as the > > version. > > > - Version.java has been reverted to remove all changes corresponding to > > > 1.8.0 > > > - CommandInitializer.java has been reverted to remove changes for 1.8.0 > > > - LuceneIndexCommandsJUnitTest.java has been modified to change > > > Version.GEODE_180 to GEODE_170 > > > - LuceneIndexCommands.java has been modified to change > Version.GEODE_180 > > > to GEODE_170 > > > -TXCommitMessage.java has been modified to change Version.GEODE_180 to > > > GEODE_170 > > > > > > I will be getting in touch with the individual developers to verify my > > > changes. > > > The branch will be update once we get a green light on these changes. > > > > > > Still need updates on these tickets: > > > > > > GEODE-5600 - [Patrick Rhomberg] > > > GEODE-5578 - [Robert Houghton] > > > GEODE-5492 - [Robert Houghton] > > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > > > > These tickets have commits into develop but they are still open with > fix > > > version as 1.8.0 > > > > > > Regards > > > Nabarun Nag > > > > > > > > > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > > > > > >> I have resolved GEODE-5254 > > >> > > >> Dale > > >> > > >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > > >> > > > >> > Requesting status update on the following JIRA tickets. These > tickets > > >> have > > >> > commits into develop against its name but the status is still open / > > >> > unresolved. > > >> > > > >> > GEODE-5600 - [Patrick Rhomberg] > > >> > GEODE-5578 - [Robert Houghton] > > >> > GEODE-5492 - [Robert Houghton] > > >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > >> > GEODE-5254 - [Dale Emery] > > >> > > > >> > GEODE-4794 - [Sai] > > >> > GEODE-5594 - [Sai] > > >> > > > >> > Regards > > >> > Nabarun Nag > > >> > > > >> > > > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag > wrote: > > >> > > > >> >> > > >> >> Please continue using 1.7.0 as a fix version in JIRA till the email > > >> comes > > >> >> in that the 1.7.0 release branch has be cut. > > >> >> > > >> >> Changing the fixed version for the following tickets to 1.7.0 from > > >> 1.8.0 > > >> >> as these fixes will be included in the 1.7.0 release > > >> >> > > >> >> GEODE-5671 > > >> >> GEODE-5662 > > >> >> GEODE-5660 > > >> >> GEODE-5652 > > >> >> > > >> >> Regards > > >> >> Nabarun Nag > > >> >> > > >> >> > > >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag > wrote: > > >> >> > > >> >>> A new feature of get/set cluster config was added as new feature > to > > >> gfsh. > > >> >>> This needs to be added to the documentation. > > >> >>> Once this is done, the branch will be ready. > > >> >>> > > >> >>> Regards > > >> >>> Nabarun > > >> >>> > > >> >>> > > >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < > > >> amurm...@pivotal.io> > > >> >>> wrote: > > >> >>> > > >> Nabarun, do you still see anything blocking cutting the release > at > > >> this > > >> point? > > >> > > >> Maybe we can even get a pipeline going today? 😳 > > >> > > >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > > >> sai.boorlaga...@gmail.com > > >> > wrote: > > >> > > >> > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have > > the > > >> code > > >> > ready. > > >> > > > >> > GEODE-5594, adds a new flag to enable hostname validation and is > > >> disabled > > >> > by default so we are good with changes that are already merged > and > > >> > documentation for GEODE-5594 is ready merged. > > >> > > > >> > Naba, after the branch is cut we should delete windows jobs from > > the > > >> branch > > >> > before we create the pipeline for 1.7. > > >> > > > >> > Apologies for holding up the release. > > >> > > > >> > Sai. >
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
So the issue is that it takes longer to start than previous releases? Also, is this wait time only when using Gfsh to create gateway-receiver? On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > Currently we have a minor issue in the release branch as pointed out by > Barry O. > We will wait till a resolution is figured out for this issue. > > Steps: > 1. create locator > 2. start server --name=server1 --server-port=40404 > 3. start server --name=server2 --server-port=40405 > 4. create gateway-receiver --member=server1 > 5. create gateway-receiver --member=server2 `This gets stuck for 2 minutes` > > Is the 2 minute wait time acceptable? Should we document it? When we revert > GEODE-5591, this issue does not happen. > > Regards > Nabarun Nag > > On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > > > Status Update on release process for 1.7.0 > > - checkPom files are being modified to have version as 1.7.0 instead of > > 1.8.0-SNAPSHOT > > - gradle.properties file has been modified to reflect 1.7.0 as the > version. > > - Version.java has been reverted to remove all changes corresponding to > > 1.8.0 > > - CommandInitializer.java has been reverted to remove changes for 1.8.0 > > - LuceneIndexCommandsJUnitTest.java has been modified to change > > Version.GEODE_180 to GEODE_170 > > - LuceneIndexCommands.java has been modified to change Version.GEODE_180 > > to GEODE_170 > > -TXCommitMessage.java has been modified to change Version.GEODE_180 to > > GEODE_170 > > > > I will be getting in touch with the individual developers to verify my > > changes. > > The branch will be update once we get a green light on these changes. > > > > Still need updates on these tickets: > > > > GEODE-5600 - [Patrick Rhomberg] > > GEODE-5578 - [Robert Houghton] > > GEODE-5492 - [Robert Houghton] > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > > These tickets have commits into develop but they are still open with fix > > version as 1.8.0 > > > > Regards > > Nabarun Nag > > > > > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > > > >> I have resolved GEODE-5254 > >> > >> Dale > >> > >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > >> > > >> > Requesting status update on the following JIRA tickets. These tickets > >> have > >> > commits into develop against its name but the status is still open / > >> > unresolved. > >> > > >> > GEODE-5600 - [Patrick Rhomberg] > >> > GEODE-5578 - [Robert Houghton] > >> > GEODE-5492 - [Robert Houghton] > >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > >> > GEODE-5254 - [Dale Emery] > >> > > >> > GEODE-4794 - [Sai] > >> > GEODE-5594 - [Sai] > >> > > >> > Regards > >> > Nabarun Nag > >> > > >> > > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag wrote: > >> > > >> >> > >> >> Please continue using 1.7.0 as a fix version in JIRA till the email > >> comes > >> >> in that the 1.7.0 release branch has be cut. > >> >> > >> >> Changing the fixed version for the following tickets to 1.7.0 from > >> 1.8.0 > >> >> as these fixes will be included in the 1.7.0 release > >> >> > >> >> GEODE-5671 > >> >> GEODE-5662 > >> >> GEODE-5660 > >> >> GEODE-5652 > >> >> > >> >> Regards > >> >> Nabarun Nag > >> >> > >> >> > >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag wrote: > >> >> > >> >>> A new feature of get/set cluster config was added as new feature to > >> gfsh. > >> >>> This needs to be added to the documentation. > >> >>> Once this is done, the branch will be ready. > >> >>> > >> >>> Regards > >> >>> Nabarun > >> >>> > >> >>> > >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < > >> amurm...@pivotal.io> > >> >>> wrote: > >> >>> > >> Nabarun, do you still see anything blocking cutting the release at > >> this > >> point? > >> > >> Maybe we can even get a pipeline going today? 😳 > >> > >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > >> sai.boorlaga...@gmail.com > >> > wrote: > >> > >> > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have > the > >> code > >> > ready. > >> > > >> > GEODE-5594, adds a new flag to enable hostname validation and is > >> disabled > >> > by default so we are good with changes that are already merged and > >> > documentation for GEODE-5594 is ready merged. > >> > > >> > Naba, after the branch is cut we should delete windows jobs from > the > >> branch > >> > before we create the pipeline for 1.7. > >> > > >> > Apologies for holding up the release. > >> > > >> > Sai. > >> > > >> > On Fri, Aug 31, 2018, 10:23 AM Nabarun Nag > wrote: > >> > > >> >> I am waiting on the documentation tickets to get closed before > >> cutting > >> > the > >> >> branch. > >> >> > >> >> Regards > >> >> Nabarun Nag > >> >> > >> >> On Fri, Aug 31, 2018 at 10:18 AM Anthony Baker < > aba...@pivotal.io> > >> > wrote: > >> >> > >> >>> Perhaps we should cut 1.7.0 without these changes to
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
Reverting GEODE-5591 results in code that can produce an infinite loop, so I don't feel that's a viable option. I feel as though the code treats bind exceptions as transient occurrences, but my direct experience with them leads me to the opposite conclusion. I don't believe a long wait time is going to change the situation, especially since a TCP timeout scenario can take up to 30 minutes to resolve itself. I believe it is better to fail fast and hard, so I would suggest either failing immediately or a very short timeout, say 5 or 10 seconds at most. On Tue, Sep 4, 2018 at 4:03 PM Nabarun Nag wrote: > Currently we have a minor issue in the release branch as pointed out by > Barry O. > We will wait till a resolution is figured out for this issue. > > Steps: > 1. create locator > 2. start server --name=server1 --server-port=40404 > 3. start server --name=server2 --server-port=40405 > 4. create gateway-receiver --member=server1 > 5. create gateway-receiver --member=server2 `This gets stuck for 2 minutes` > > Is the 2 minute wait time acceptable? Should we document it? When we revert > GEODE-5591, this issue does not happen. > > Regards > Nabarun Nag > > On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > > > Status Update on release process for 1.7.0 > > - checkPom files are being modified to have version as 1.7.0 instead of > > 1.8.0-SNAPSHOT > > - gradle.properties file has been modified to reflect 1.7.0 as the > version. > > - Version.java has been reverted to remove all changes corresponding to > > 1.8.0 > > - CommandInitializer.java has been reverted to remove changes for 1.8.0 > > - LuceneIndexCommandsJUnitTest.java has been modified to change > > Version.GEODE_180 to GEODE_170 > > - LuceneIndexCommands.java has been modified to change Version.GEODE_180 > > to GEODE_170 > > -TXCommitMessage.java has been modified to change Version.GEODE_180 to > > GEODE_170 > > > > I will be getting in touch with the individual developers to verify my > > changes. > > The branch will be update once we get a green light on these changes. > > > > Still need updates on these tickets: > > > > GEODE-5600 - [Patrick Rhomberg] > > GEODE-5578 - [Robert Houghton] > > GEODE-5492 - [Robert Houghton] > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > > > These tickets have commits into develop but they are still open with fix > > version as 1.8.0 > > > > Regards > > Nabarun Nag > > > > > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > > > >> I have resolved GEODE-5254 > >> > >> Dale > >> > >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > >> > > >> > Requesting status update on the following JIRA tickets. These tickets > >> have > >> > commits into develop against its name but the status is still open / > >> > unresolved. > >> > > >> > GEODE-5600 - [Patrick Rhomberg] > >> > GEODE-5578 - [Robert Houghton] > >> > GEODE-5492 - [Robert Houghton] > >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > >> > GEODE-5254 - [Dale Emery] > >> > > >> > GEODE-4794 - [Sai] > >> > GEODE-5594 - [Sai] > >> > > >> > Regards > >> > Nabarun Nag > >> > > >> > > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag wrote: > >> > > >> >> > >> >> Please continue using 1.7.0 as a fix version in JIRA till the email > >> comes > >> >> in that the 1.7.0 release branch has be cut. > >> >> > >> >> Changing the fixed version for the following tickets to 1.7.0 from > >> 1.8.0 > >> >> as these fixes will be included in the 1.7.0 release > >> >> > >> >> GEODE-5671 > >> >> GEODE-5662 > >> >> GEODE-5660 > >> >> GEODE-5652 > >> >> > >> >> Regards > >> >> Nabarun Nag > >> >> > >> >> > >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag wrote: > >> >> > >> >>> A new feature of get/set cluster config was added as new feature to > >> gfsh. > >> >>> This needs to be added to the documentation. > >> >>> Once this is done, the branch will be ready. > >> >>> > >> >>> Regards > >> >>> Nabarun > >> >>> > >> >>> > >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < > >> amurm...@pivotal.io> > >> >>> wrote: > >> >>> > >> Nabarun, do you still see anything blocking cutting the release at > >> this > >> point? > >> > >> Maybe we can even get a pipeline going today? 😳 > >> > >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > >> sai.boorlaga...@gmail.com > >> > wrote: > >> > >> > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have > the > >> code > >> > ready. > >> > > >> > GEODE-5594, adds a new flag to enable hostname validation and is > >> disabled > >> > by default so we are good with changes that are already merged and > >> > documentation for GEODE-5594 is ready merged. > >> > > >> > Naba, after the branch is cut we should delete windows jobs from > the > >> branch > >> > before we create the pipeline for 1.7. > >> > > >> > Apologies for holding up the release. > >> > > >> > Sai. > >> > > >> > On Fri, Aug 31, 2018, 10
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
Currently we have a minor issue in the release branch as pointed out by Barry O. We will wait till a resolution is figured out for this issue. Steps: 1. create locator 2. start server --name=server1 --server-port=40404 3. start server --name=server2 --server-port=40405 4. create gateway-receiver --member=server1 5. create gateway-receiver --member=server2 `This gets stuck for 2 minutes` Is the 2 minute wait time acceptable? Should we document it? When we revert GEODE-5591, this issue does not happen. Regards Nabarun Nag On Tue, Sep 4, 2018 at 10:50 AM Nabarun Nag wrote: > Status Update on release process for 1.7.0 > - checkPom files are being modified to have version as 1.7.0 instead of > 1.8.0-SNAPSHOT > - gradle.properties file has been modified to reflect 1.7.0 as the version. > - Version.java has been reverted to remove all changes corresponding to > 1.8.0 > - CommandInitializer.java has been reverted to remove changes for 1.8.0 > - LuceneIndexCommandsJUnitTest.java has been modified to change > Version.GEODE_180 to GEODE_170 > - LuceneIndexCommands.java has been modified to change Version.GEODE_180 > to GEODE_170 > -TXCommitMessage.java has been modified to change Version.GEODE_180 to > GEODE_170 > > I will be getting in touch with the individual developers to verify my > changes. > The branch will be update once we get a green light on these changes. > > Still need updates on these tickets: > > GEODE-5600 - [Patrick Rhomberg] > GEODE-5578 - [Robert Houghton] > GEODE-5492 - [Robert Houghton] > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > These tickets have commits into develop but they are still open with fix > version as 1.8.0 > > Regards > Nabarun Nag > > > > On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > >> I have resolved GEODE-5254 >> >> Dale >> >> > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: >> > >> > Requesting status update on the following JIRA tickets. These tickets >> have >> > commits into develop against its name but the status is still open / >> > unresolved. >> > >> > GEODE-5600 - [Patrick Rhomberg] >> > GEODE-5578 - [Robert Houghton] >> > GEODE-5492 - [Robert Houghton] >> > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] >> > GEODE-5254 - [Dale Emery] >> > >> > GEODE-4794 - [Sai] >> > GEODE-5594 - [Sai] >> > >> > Regards >> > Nabarun Nag >> > >> > >> > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag wrote: >> > >> >> >> >> Please continue using 1.7.0 as a fix version in JIRA till the email >> comes >> >> in that the 1.7.0 release branch has be cut. >> >> >> >> Changing the fixed version for the following tickets to 1.7.0 from >> 1.8.0 >> >> as these fixes will be included in the 1.7.0 release >> >> >> >> GEODE-5671 >> >> GEODE-5662 >> >> GEODE-5660 >> >> GEODE-5652 >> >> >> >> Regards >> >> Nabarun Nag >> >> >> >> >> >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag wrote: >> >> >> >>> A new feature of get/set cluster config was added as new feature to >> gfsh. >> >>> This needs to be added to the documentation. >> >>> Once this is done, the branch will be ready. >> >>> >> >>> Regards >> >>> Nabarun >> >>> >> >>> >> >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann < >> amurm...@pivotal.io> >> >>> wrote: >> >>> >> Nabarun, do you still see anything blocking cutting the release at >> this >> point? >> >> Maybe we can even get a pipeline going today? 😳 >> >> On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < >> sai.boorlaga...@gmail.com >> > wrote: >> >> > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have the >> code >> > ready. >> > >> > GEODE-5594, adds a new flag to enable hostname validation and is >> disabled >> > by default so we are good with changes that are already merged and >> > documentation for GEODE-5594 is ready merged. >> > >> > Naba, after the branch is cut we should delete windows jobs from the >> branch >> > before we create the pipeline for 1.7. >> > >> > Apologies for holding up the release. >> > >> > Sai. >> > >> > On Fri, Aug 31, 2018, 10:23 AM Nabarun Nag wrote: >> > >> >> I am waiting on the documentation tickets to get closed before >> cutting >> > the >> >> branch. >> >> >> >> Regards >> >> Nabarun Nag >> >> >> >> On Fri, Aug 31, 2018 at 10:18 AM Anthony Baker >> > wrote: >> >> >> >>> Perhaps we should cut 1.7.0 without these changes to give us more >> time >> > to >> >>> review and complete the work. >> >>> >> >>> Thoughts? >> >>> >> >>> Anthony >> >>> >> >>> >> On Aug 31, 2018, at 8:03 AM, Sai Boorlagadda < >> >> sai.boorlaga...@gmail.com> >> >>> wrote: >> >> I haven't yet merged GEODE-5338. The PR changes the existing >> behavior >> >> and >> is not acceptable. >> Working on changing the implementation to have a default value >> > derived >> b
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1030 was SUCCESSFUL (with 2423 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #1030 was successful. --- Scheduled 2425 tests in total. https://build.spring.io/browse/SGF-NAG-1030/ -- This message is automatically generated by Atlassian Bamboo
Re: [DISCUSS] Apache Geode 1.7.0 release branch created
Status Update on release process for 1.7.0 - checkPom files are being modified to have version as 1.7.0 instead of 1.8.0-SNAPSHOT - gradle.properties file has been modified to reflect 1.7.0 as the version. - Version.java has been reverted to remove all changes corresponding to 1.8.0 - CommandInitializer.java has been reverted to remove changes for 1.8.0 - LuceneIndexCommandsJUnitTest.java has been modified to change Version.GEODE_180 to GEODE_170 - LuceneIndexCommands.java has been modified to change Version.GEODE_180 to GEODE_170 -TXCommitMessage.java has been modified to change Version.GEODE_180 to GEODE_170 I will be getting in touch with the individual developers to verify my changes. The branch will be update once we get a green light on these changes. Still need updates on these tickets: GEODE-5600 - [Patrick Rhomberg] GEODE-5578 - [Robert Houghton] GEODE-5492 - [Robert Houghton] GEODE-5280 - [xiaojian zhou & Biju Kunjummen] These tickets have commits into develop but they are still open with fix version as 1.8.0 Regards Nabarun Nag On Fri, Aug 31, 2018 at 3:38 PM Dale Emery wrote: > I have resolved GEODE-5254 > > Dale > > > On Aug 31, 2018, at 3:34 PM, Nabarun Nag wrote: > > > > Requesting status update on the following JIRA tickets. These tickets > have > > commits into develop against its name but the status is still open / > > unresolved. > > > > GEODE-5600 - [Patrick Rhomberg] > > GEODE-5578 - [Robert Houghton] > > GEODE-5492 - [Robert Houghton] > > GEODE-5280 - [xiaojian zhou & Biju Kunjummen] > > GEODE-5254 - [Dale Emery] > > > > GEODE-4794 - [Sai] > > GEODE-5594 - [Sai] > > > > Regards > > Nabarun Nag > > > > > > On Fri, Aug 31, 2018 at 3:18 PM Nabarun Nag wrote: > > > >> > >> Please continue using 1.7.0 as a fix version in JIRA till the email > comes > >> in that the 1.7.0 release branch has be cut. > >> > >> Changing the fixed version for the following tickets to 1.7.0 from 1.8.0 > >> as these fixes will be included in the 1.7.0 release > >> > >> GEODE-5671 > >> GEODE-5662 > >> GEODE-5660 > >> GEODE-5652 > >> > >> Regards > >> Nabarun Nag > >> > >> > >> On Fri, Aug 31, 2018 at 2:20 PM Nabarun Nag wrote: > >> > >>> A new feature of get/set cluster config was added as new feature to > gfsh. > >>> This needs to be added to the documentation. > >>> Once this is done, the branch will be ready. > >>> > >>> Regards > >>> Nabarun > >>> > >>> > >>> On Fri, Aug 31, 2018 at 2:15 PM Alexander Murmann > > >>> wrote: > >>> > Nabarun, do you still see anything blocking cutting the release at > this > point? > > Maybe we can even get a pipeline going today? 😳 > > On Fri, Aug 31, 2018 at 10:38 AM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > > wrote: > > > We can go ahead and cut 1.7 with out GEODE-5338 as I don't have the > code > > ready. > > > > GEODE-5594, adds a new flag to enable hostname validation and is > disabled > > by default so we are good with changes that are already merged and > > documentation for GEODE-5594 is ready merged. > > > > Naba, after the branch is cut we should delete windows jobs from the > branch > > before we create the pipeline for 1.7. > > > > Apologies for holding up the release. > > > > Sai. > > > > On Fri, Aug 31, 2018, 10:23 AM Nabarun Nag wrote: > > > >> I am waiting on the documentation tickets to get closed before > cutting > > the > >> branch. > >> > >> Regards > >> Nabarun Nag > >> > >> On Fri, Aug 31, 2018 at 10:18 AM Anthony Baker > > wrote: > >> > >>> Perhaps we should cut 1.7.0 without these changes to give us more > time > > to > >>> review and complete the work. > >>> > >>> Thoughts? > >>> > >>> Anthony > >>> > >>> > On Aug 31, 2018, at 8:03 AM, Sai Boorlagadda < > >> sai.boorlaga...@gmail.com> > >>> wrote: > > I haven't yet merged GEODE-5338. The PR changes the existing > behavior > >> and > is not acceptable. > Working on changing the implementation to have a default value > > derived > based on how user > wants to configure SSL. > > Sai > > On Wed, Aug 29, 2018 at 11:45 AM Sai Boorlagadda < > >>> sai.boorlaga...@gmail.com> > wrote: > > > I have merged GEODE-5594 to develop. > > > > GEODE-5338 is now waiting for PR review and precheckin. > > > > Sai > > > > On Tue, Aug 28, 2018 at 10:30 AM Sai Boorlagadda < > > sai.boorlaga...@gmail.com> wrote: > > > >> GEODE-5338 is downvoted for the security concerns related to > > trusting > >> the default trust store and thus resulted in an improvement to > add > > a > >> hostname > >> validation as a feature before we can support trusting def
Re: Geode Wiki Write/Edit Permissions
Hi Ryan, You should have access now. Thanks! -Dan On Tue, Sep 4, 2018 at 9:45 AM, Ryan McMahon wrote: > Follow up: looks like my wiki username is just 'rmcmahon'. > > Thanks, > Ryan McMahon > rmcma...@pivotal.io > > On Tue, Sep 4, 2018 at 9:21 AM, Ryan McMahon wrote: > > > Hello, > > > > I'd like to request write/edit permissions on the Geode wiki. My Apache > > username is mcmellawatt and the email address I used with Confluence is > > rmcma...@pivotal.io. > > > > Thanks, > > Ryan McMahon > > rmcma...@pivotal.io > > >
Re: Geode Wiki Write/Edit Permissions
Follow up: looks like my wiki username is just 'rmcmahon'. Thanks, Ryan McMahon rmcma...@pivotal.io On Tue, Sep 4, 2018 at 9:21 AM, Ryan McMahon wrote: > Hello, > > I'd like to request write/edit permissions on the Geode wiki. My Apache > username is mcmellawatt and the email address I used with Confluence is > rmcma...@pivotal.io. > > Thanks, > Ryan McMahon > rmcma...@pivotal.io >
Geode Wiki Write/Edit Permissions
Hello, I'd like to request write/edit permissions on the Geode wiki. My Apache username is mcmellawatt and the email address I used with Confluence is rmcma...@pivotal.io. Thanks, Ryan McMahon rmcma...@pivotal.io
