[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15769133#comment-15769133
 ] 

ASF subversion and git services commented on GEODE-165:
---

Commit 93d4455d861413e5bb922d06d4775929b39c6c81 in geode's branch 
refs/heads/develop from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=93d4455 ]

GEODE-165: Removed OQL generated files and added the target into 
geode-core/build.gradle.

GEODE-165 : Updating spotless configuration to exclude 'generated-src' 
directory.


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15769057#comment-15769057
 ] 

ASF GitHub Bot commented on GEODE-2109:
---

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/296
  
Thanks @upthewaterspout for your assistance in resolving it.


> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[Deepak Dixit (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15769028#comment-15769028
 ] 

Deepak Dixit commented on GEODE-2109:
-

I think this is for [~deepakddixit]  not for [~deepak.dixit] :)

> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 54964: GEODE-2243: reference the formatter relative to geode-core and not the root project

[Jens Deppe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54964/
---

Review request for geode, Anthony Baker, Mark Bretl, and Dan Smith.


Repository: geode


Description
---

GEODE-2243: reference the formatter relative to geode-core and not the root 
project

Hopefully this change will be more accessible. Apologies for the previous 
breakage.


Diffs
-

  build.gradle 360310fbd58b97354b0b5fb60801540fe6f80dee 

Diff: https://reviews.apache.org/r/54964/diff/


Testing
---

Build under various root directory structures


Thanks,

Jens Deppe

Re: GEODE-2243: Adjust path of spotless formatter

[Dan Smith]

Hi Scott,

The issue is that this line only works if your geode checkout is in a
folder called open:

eclipseFormatFile
"${rootProject.projectDir}/../open/etc/eclipse-java-google-style.xml"

That's not going to work for many people; the default name of the folder is
geode if you do git clone https://git-wip-us.apache.org/repos/asf/geode.git.

-Dan

On Wed, Dec 21, 2016 at 6:11 PM, Scott Jewell  wrote:

> Hi Dan,
>
> Since the spotless stuff lives on the open side, you just need to make sure
> to pull a fresh copy of the open side in order for the closed side build to
> work.
>
> I suppose we could have left the redundant xml file in the closed branch
> for a
> while so that stale open branches would still allow the fresh closed side
> to build.
>
> Talk with ya later.
>
> On Wed, Dec 21, 2016 at 5:49 PM, Dan Smith  wrote:
>
> > I'm seeing the same thing. I went ahead and reverted the change so our
> > build isn't broken.
> >
> > -Dan
> >
> > On Wed, Dec 21, 2016 at 4:49 PM, Mark Bretl  wrote:
> >
> > > Jens,
> > >
> > > Please revert this commit. I feel like the JIRA issue, GEODE-2243, was
> > done
> > > with separate specific environment in mind and not done for the
> > > community. This does not work for standard Geode development
> > environment...
> > >
> > > Unable to apply step Eclipse Formatter to
> src/main/java/org/apache/geode
> > > /rest/internal/web/util/ValidationUtils.java: Eclipse formatter file
> > > '/Users/mbretl/bldz/open/etc/eclipse-java-google-style.xml' does not
> > > exist.
> > >
> > > --Mark
> > > -- Forwarded message --
> > > From: 
> > > Date: Wed, Dec 21, 2016 at 2:53 PM
> > > Subject: geode git commit: GEODE-2243: Adjust path of spotless
> formatter
> > > To: comm...@geode.apache.org
> > >
> > >
> > > Repository: geode
> > > Updated Branches:
> > >   refs/heads/develop eba189bb1 -> c1998d739
> > >
> > >
> > > GEODE-2243: Adjust path of spotless formatter
> > >
> > > - This allows projects which depend on Geode to use Geode's formatter
> > >
> > > Signed-off-by: Scott Jewell 
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/geode/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/c1998d73
> > > Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/c1998d73
> > > Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/c1998d73
> > >
> > > Branch: refs/heads/develop
> > > Commit: c1998d7398b837ee1e699bfd1952719443045d71
> > > Parents: eba189b
> > > Author: Jens Deppe 
> > > Authored: Wed Dec 21 14:52:11 2016 -0800
> > > Committer: Jens Deppe 
> > > Committed: Wed Dec 21 14:53:25 2016 -0800
> > >
> > > --
> > >  build.gradle | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > --
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/geode/blob/c1998d73/
> build.gradle
> > > --
> > > diff --git a/build.gradle b/build.gradle
> > > index 360310f..d788250 100755
> > > --- a/build.gradle
> > > +++ b/build.gradle
> > > @@ -91,7 +91,7 @@ subprojects {
> > >spotless {
> > >  lineEndings = 'unix';
> > >  java {
> > > -  eclipseFormatFile "${rootProject.projectDir}/etc
> > > /eclipse-java-google-style.xml"
> > > +  eclipseFormatFile "${rootProject.projectDir}/../
> > > open/etc/eclipse-java-google-style.xml"
> > >  }
> > >}
> > >  }
> > >
> >
>
>
>
> --
> Scott Jewell
> sjew...@pivotal.io
>

Re: New proposal for type definitons

[Dan Smith]

I'm assuming the type ids here are a different set than the type ids used
with regular PDX serialization so they won't conflict if the pdx registry
assigns 1 to some class and a user puts @typeId: 1 in their json?

I'm concerned that this won't really address the type explosion issue.
Users that are able to go to the effort of adding these typeIds to all of
their json are probably users that can produce consistently formatted json
in the first place. Users that have inconsistently formatted json are
probably not going to want or be able to add these type ids.

It might be better for us to pursue a way to store arbitrary documents that
are self describing. Our current approach for json documents is assuming
that the documents are all consistently formatted. We are infer a schema
for their documents store the field names in the type registry and the
field values in the serialized data. If we give people the option to store
and query self describing values, then users with inconsistent json could
just use that option and pay the extra storage cost.

-Dan

On Tue, Dec 20, 2016 at 4:53 PM, Udo Kohlmeyer  wrote:

> Hey there,
>
> I've just completed a new proposal on the wiki for a new mechanism that
> could be used to define a type definition for an object.
> https://cwiki.apache.org/confluence/display/GEODE/Custom+
> External+Type+Definition+Proposal+for+JSON
>
> Primarily the new type definition proposal will hopefully help with the
> "structuring" of JSON document definitions in a manner that will allow
> users to submit JSON documents for data types without the need to provide
> every field of the whole domain object type.
>
> Please review and comment as required.
>
> --Udo
>
>

Re: GEODE-2243: Adjust path of spotless formatter

[Scott Jewell]

Hi Dan,

Since the spotless stuff lives on the open side, you just need to make sure
to pull a fresh copy of the open side in order for the closed side build to
work.

I suppose we could have left the redundant xml file in the closed branch
for a
while so that stale open branches would still allow the fresh closed side
to build.

Talk with ya later.

On Wed, Dec 21, 2016 at 5:49 PM, Dan Smith  wrote:

> I'm seeing the same thing. I went ahead and reverted the change so our
> build isn't broken.
>
> -Dan
>
> On Wed, Dec 21, 2016 at 4:49 PM, Mark Bretl  wrote:
>
> > Jens,
> >
> > Please revert this commit. I feel like the JIRA issue, GEODE-2243, was
> done
> > with separate specific environment in mind and not done for the
> > community. This does not work for standard Geode development
> environment...
> >
> > Unable to apply step Eclipse Formatter to src/main/java/org/apache/geode
> > /rest/internal/web/util/ValidationUtils.java: Eclipse formatter file
> > '/Users/mbretl/bldz/open/etc/eclipse-java-google-style.xml' does not
> > exist.
> >
> > --Mark
> > -- Forwarded message --
> > From: 
> > Date: Wed, Dec 21, 2016 at 2:53 PM
> > Subject: geode git commit: GEODE-2243: Adjust path of spotless formatter
> > To: comm...@geode.apache.org
> >
> >
> > Repository: geode
> > Updated Branches:
> >   refs/heads/develop eba189bb1 -> c1998d739
> >
> >
> > GEODE-2243: Adjust path of spotless formatter
> >
> > - This allows projects which depend on Geode to use Geode's formatter
> >
> > Signed-off-by: Scott Jewell 
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/geode/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/c1998d73
> > Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/c1998d73
> > Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/c1998d73
> >
> > Branch: refs/heads/develop
> > Commit: c1998d7398b837ee1e699bfd1952719443045d71
> > Parents: eba189b
> > Author: Jens Deppe 
> > Authored: Wed Dec 21 14:52:11 2016 -0800
> > Committer: Jens Deppe 
> > Committed: Wed Dec 21 14:53:25 2016 -0800
> >
> > --
> >  build.gradle | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/geode/blob/c1998d73/build.gradle
> > --
> > diff --git a/build.gradle b/build.gradle
> > index 360310f..d788250 100755
> > --- a/build.gradle
> > +++ b/build.gradle
> > @@ -91,7 +91,7 @@ subprojects {
> >spotless {
> >  lineEndings = 'unix';
> >  java {
> > -  eclipseFormatFile "${rootProject.projectDir}/etc
> > /eclipse-java-google-style.xml"
> > +  eclipseFormatFile "${rootProject.projectDir}/../
> > open/etc/eclipse-java-google-style.xml"
> >  }
> >}
> >  }
> >
>



-- 
Scott Jewell
sjew...@pivotal.io

Re: GEODE-2243: Adjust path of spotless formatter

[Dan Smith]

I'm seeing the same thing. I went ahead and reverted the change so our
build isn't broken.

-Dan

On Wed, Dec 21, 2016 at 4:49 PM, Mark Bretl  wrote:

> Jens,
>
> Please revert this commit. I feel like the JIRA issue, GEODE-2243, was done
> with separate specific environment in mind and not done for the
> community. This does not work for standard Geode development environment...
>
> Unable to apply step Eclipse Formatter to src/main/java/org/apache/geode
> /rest/internal/web/util/ValidationUtils.java: Eclipse formatter file
> '/Users/mbretl/bldz/open/etc/eclipse-java-google-style.xml' does not
> exist.
>
> --Mark
> -- Forwarded message --
> From: 
> Date: Wed, Dec 21, 2016 at 2:53 PM
> Subject: geode git commit: GEODE-2243: Adjust path of spotless formatter
> To: comm...@geode.apache.org
>
>
> Repository: geode
> Updated Branches:
>   refs/heads/develop eba189bb1 -> c1998d739
>
>
> GEODE-2243: Adjust path of spotless formatter
>
> - This allows projects which depend on Geode to use Geode's formatter
>
> Signed-off-by: Scott Jewell 
>
>
> Project: http://git-wip-us.apache.org/repos/asf/geode/repo
> Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/c1998d73
> Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/c1998d73
> Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/c1998d73
>
> Branch: refs/heads/develop
> Commit: c1998d7398b837ee1e699bfd1952719443045d71
> Parents: eba189b
> Author: Jens Deppe 
> Authored: Wed Dec 21 14:52:11 2016 -0800
> Committer: Jens Deppe 
> Committed: Wed Dec 21 14:53:25 2016 -0800
>
> --
>  build.gradle | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/geode/blob/c1998d73/build.gradle
> --
> diff --git a/build.gradle b/build.gradle
> index 360310f..d788250 100755
> --- a/build.gradle
> +++ b/build.gradle
> @@ -91,7 +91,7 @@ subprojects {
>spotless {
>  lineEndings = 'unix';
>  java {
> -  eclipseFormatFile "${rootProject.projectDir}/etc
> /eclipse-java-google-style.xml"
> +  eclipseFormatFile "${rootProject.projectDir}/../
> open/etc/eclipse-java-google-style.xml"
>  }
>}
>  }
>

[jira] [Commented] (GEODE-2243) Modify path to spotless formatter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768727#comment-15768727
 ] 

ASF subversion and git services commented on GEODE-2243:


Commit d30e9abc2ede49054abd7c1ec7835f86567d20ca in geode's branch 
refs/heads/develop from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d30e9ab ]

Revert "GEODE-2243: Adjust path of spotless formatter"

This reverts commit c1998d7398b837ee1e699bfd1952719443045d71.


> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Fwd: geode git commit: GEODE-2243: Adjust path of spotless formatter

[Mark Bretl]

Jens,

Please revert this commit. I feel like the JIRA issue, GEODE-2243, was done
with separate specific environment in mind and not done for the
community. This does not work for standard Geode development environment...

Unable to apply step Eclipse Formatter to src/main/java/org/apache/geode
/rest/internal/web/util/ValidationUtils.java: Eclipse formatter file
'/Users/mbretl/bldz/open/etc/eclipse-java-google-style.xml' does not exist.

--Mark
-- Forwarded message --
From: 
Date: Wed, Dec 21, 2016 at 2:53 PM
Subject: geode git commit: GEODE-2243: Adjust path of spotless formatter
To: comm...@geode.apache.org


Repository: geode
Updated Branches:
  refs/heads/develop eba189bb1 -> c1998d739


GEODE-2243: Adjust path of spotless formatter

- This allows projects which depend on Geode to use Geode's formatter

Signed-off-by: Scott Jewell 


Project: http://git-wip-us.apache.org/repos/asf/geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/c1998d73
Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/c1998d73
Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/c1998d73

Branch: refs/heads/develop
Commit: c1998d7398b837ee1e699bfd1952719443045d71
Parents: eba189b
Author: Jens Deppe 
Authored: Wed Dec 21 14:52:11 2016 -0800
Committer: Jens Deppe 
Committed: Wed Dec 21 14:53:25 2016 -0800

--
 build.gradle | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/geode/blob/c1998d73/build.gradle
--
diff --git a/build.gradle b/build.gradle
index 360310f..d788250 100755
--- a/build.gradle
+++ b/build.gradle
@@ -91,7 +91,7 @@ subprojects {
   spotless {
 lineEndings = 'unix';
 java {
-  eclipseFormatFile "${rootProject.projectDir}/etc
/eclipse-java-google-style.xml"
+  eclipseFormatFile "${rootProject.projectDir}/../
open/etc/eclipse-java-google-style.xml"
 }
   }
 }

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Kirk Lund (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768569#comment-15768569
 ] 

Kirk Lund commented on GEODE-2238:
--

There are two request/response messages involving cluster config:

1) SharedConfigurationStatusRequest/SharedConfigurationStatusResponse -- used 
only to get status of cluster config service such as for "status locator" 
command.

This is implemented with a Future so that handling the 
SharedConfigurationStatusRequest will correctly wait on a Future until cluster 
config has been initialized:
{code:java}
  public SharedConfigurationStatusResponse getSharedConfigurationStatus() {
ExecutorService es =
((GemFireCacheImpl) 
myCache).getDistributionManager().getWaitingThreadPool();
Future statusFuture =
es.submit(new FetchSharedConfigStatus());
SharedConfigurationStatusResponse response = null;

try {
  response = statusFuture.get(5, TimeUnit.SECONDS);
} catch (Exception e) {
  logger.info("Exception occured while fetching the status {}", 
CliUtil.stackTraceAsString(e));
  response = new SharedConfigurationStatusResponse();
  response.setStatus(SharedConfigurationStatus.UNDETERMINED);
}
return response;
  }
{code}

2) ConfigurationRequest/ConfigurationResponse -- used to request the actual 
cluster config and return it to a server that's starting up.

The handling of this request looks problematic. It has a retry-loop and it 
acquires a distributed lock. I don't see anything in this code -- 
SharedConfiguration.createConfigurationReponse(ConfigurationRequest) -- that is 
awaiting the initialization of cluster config. The retry loop and the locking 
would only somewhat reduce the chance of replying before initialization 
completes. We could probably remove the retry and the use of distributed lock 
service here and make it much more robust by using a Future in the way that #1 
does.

> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Dan Smith
>  Labels: Flaky
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Kirk Lund (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768547#comment-15768547
 ] 

Kirk Lund commented on GEODE-2238:
--

The LocatorStarterRule currently has a workaround related to the async 
initialization of cluster config:
{code:java}
if (locator.getConfig().getEnableClusterConfiguration()) {
  Awaitility.await().atMost(65, TimeUnit.SECONDS)
  .until(() -> assertTrue(locator.isSharedConfigurationRunning()));
}
{code}


> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Dan Smith
>  Labels: Flaky
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Anthony Baker (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768519#comment-15768519
 ] 

Anthony Baker commented on GEODE-2232:
--

Probably this discussion can be split into three parts:

- Naming changes that affect the public API
- Naming changes that affect serialization
- Naming changes that do not affect API's or serialization

I'm generally in favor of removing 'Gemfire' from names as long as we 
thoughtfully consider backwards compatibility and rolling upgrade implications.

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54924: GEODE-2238: Fix how peers discover locators with cluster config

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54924/#review159878
---


Ship it!




Ship It!

- Kirk Lund


On Dec. 21, 2016, 11:40 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54924/
> ---
> 
> (Updated Dec. 21, 2016, 11:40 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jinmei Liao, Kevin Duling, and 
> Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Call super.process last in StartupResponseWithVersionMessage, so that
> that threads waiting on the response will have the results of
> dm.addHostedLocators.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/StartupMessageReplyProcessor.java
>  de6e71fee7281df8997a76b1b8ce7b76ca72bfbf 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/StartupResponseWithVersionMessage.java
>  6276d63a4dc496cc809bcb17c52fe4f80b362379 
> 
> Diff: https://reviews.apache.org/r/54924/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 54924: GEODE-2238: Fix how peers discover locators with cluster config

[Dan Smith]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54924/
---

(Updated Dec. 21, 2016, 11:40 p.m.)


Review request for geode, Bruce Schuchardt, Jinmei Liao, Kevin Duling, and Kirk 
Lund.


Changes
---

I found another place that needs to be fixed in the StartupMessage processing. 
The reply processor stopped waiting as soon as it received one reply, which 
means there was still race where we could continue member startup before 
receiving information about locators that have cluster configuration.

With this latest fix, we will wait for all members to reply.


Repository: geode


Description
---

Call super.process last in StartupResponseWithVersionMessage, so that
that threads waiting on the response will have the results of
dm.addHostedLocators.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/StartupMessageReplyProcessor.java
 de6e71fee7281df8997a76b1b8ce7b76ca72bfbf 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/StartupResponseWithVersionMessage.java
 6276d63a4dc496cc809bcb17c52fe4f80b362379 

Diff: https://reviews.apache.org/r/54924/diff/


Testing
---


Thanks,

Dan Smith

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Kirk Lund (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768480#comment-15768480
 ] 

Kirk Lund commented on GEODE-2238:
--

I closed GEODE-2244 as a duplicate of GEODE-2238. Below is where initialization 
of cluster config is async during locator startup. I believe we need to have 
incoming requests for cluster config determine that cluster config is enabled 
and then wait on a Future for initialization of cluster config to complete.

The method in InternalLocator is startCache(DistributedSystem):
{code:java}
  private void startCache(DistributedSystem ds) {

GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
if (gfc == null) {
  logger.info("Creating cache for locator.");
  this.myCache = new CacheFactory(ds.getProperties()).create();
  gfc = (GemFireCacheImpl) this.myCache;
} else {
  logger.info("Using existing cache for locator.");
  ((InternalDistributedSystem) 
ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
}
startJmxManagerLocationService(gfc);

startSharedConfigurationService(gfc);
  }
{code}
The method startSharedConfigurationService hands off to a thread to load 
cluster config and use distributed lock service to become primary cluster 
config source. This was probably made async due to use of distributed lock 
service to keep startup responsive. Unfortunately, it opens up a race condition 
window -- if any requests come in before cluster config is ready, the locator 
will reply saying it doesn't have cluster config. I think some of our Flaky 
tests are hitting this race condition.


> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Dan Smith
>  Labels: Flaky
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2244) Cluster config start is async and may not be ready when requests start coming in

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-2244.
--
Resolution: Duplicate

> Cluster config start is async and may not be ready when requests start coming 
> in
> 
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster 
> config may reply to requests saying that it doesn't have cluster config 
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
>   private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
>   logger.info("Creating cache for locator.");
>   this.myCache = new CacheFactory(ds.getProperties()).create();
>   gfc = (GemFireCacheImpl) this.myCache;
> } else {
>   logger.info("Using existing cache for locator.");
>   ((InternalDistributedSystem) 
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
>   }
> {code}
> The method startSharedConfigurationService hands off to a thread to load 
> cluster config and use distributed lock service to become primary cluster 
> config source. This was probably made async due to use of distributed lock 
> service to keep startup responsive. Unfortunately, it opens up a race 
> condition window -- if any requests come in before cluster config is ready, 
> the locator will reply saying it doesn't have cluster config. I think some of 
> our Flaky tests are hitting this race condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-2244) Cluster config start is async and may not be ready when requests start coming in

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund closed GEODE-2244.


> Cluster config start is async and may not be ready when requests start coming 
> in
> 
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster 
> config may reply to requests saying that it doesn't have cluster config 
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
>   private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
>   logger.info("Creating cache for locator.");
>   this.myCache = new CacheFactory(ds.getProperties()).create();
>   gfc = (GemFireCacheImpl) this.myCache;
> } else {
>   logger.info("Using existing cache for locator.");
>   ((InternalDistributedSystem) 
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
>   }
> {code}
> The method startSharedConfigurationService hands off to a thread to load 
> cluster config and use distributed lock service to become primary cluster 
> config source. This was probably made async due to use of distributed lock 
> service to keep startup responsive. Unfortunately, it opens up a race 
> condition window -- if any requests come in before cluster config is ready, 
> the locator will reply saying it doesn't have cluster config. I think some of 
> our Flaky tests are hitting this race condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2244) Cluster config start is async and may not be ready when requests start coming in

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-2244:


Assignee: Kirk Lund

> Cluster config start is async and may not be ready when requests start coming 
> in
> 
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster 
> config may reply to requests saying that it doesn't have cluster config 
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
>   private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
>   logger.info("Creating cache for locator.");
>   this.myCache = new CacheFactory(ds.getProperties()).create();
>   gfc = (GemFireCacheImpl) this.myCache;
> } else {
>   logger.info("Using existing cache for locator.");
>   ((InternalDistributedSystem) 
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
>   }
> {code}
> The method startSharedConfigurationService hands off to a thread to load 
> cluster config and use distributed lock service to become primary cluster 
> config source. This was probably made async due to use of distributed lock 
> service to keep startup responsive. Unfortunately, it opens up a race 
> condition window -- if any requests come in before cluster config is ready, 
> the locator will reply saying it doesn't have cluster config. I think some of 
> our Flaky tests are hitting this race condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2244) Cluster config start is async and may not be ready when requests start coming in

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-2244:
-
Affects Version/s: 1.0.0-incubating

> Cluster config start is async and may not be ready when requests start coming 
> in
> 
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster 
> config may reply to requests saying that it doesn't have cluster config 
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
>   private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
>   logger.info("Creating cache for locator.");
>   this.myCache = new CacheFactory(ds.getProperties()).create();
>   gfc = (GemFireCacheImpl) this.myCache;
> } else {
>   logger.info("Using existing cache for locator.");
>   ((InternalDistributedSystem) 
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
>   }
> {code}
> The method startSharedConfigurationService hands off to a thread to load 
> cluster config and use distributed lock service to become primary cluster 
> config source. This was probably made async due to use of distributed lock 
> service to keep startup responsive. Unfortunately, it opens up a race 
> condition window -- if any requests come in before cluster config is ready, 
> the locator will reply saying it doesn't have cluster config. I think some of 
> our Flaky tests are hitting this race condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2244) Cluster config start is async and may not be ready when requests start coming in

[Kirk Lund (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-2244:
-
Component/s: configuration

> Cluster config start is async and may not be ready when requests start coming 
> in
> 
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster 
> config may reply to requests saying that it doesn't have cluster config 
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
>   private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
>   logger.info("Creating cache for locator.");
>   this.myCache = new CacheFactory(ds.getProperties()).create();
>   gfc = (GemFireCacheImpl) this.myCache;
> } else {
>   logger.info("Using existing cache for locator.");
>   ((InternalDistributedSystem) 
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
>   }
> {code}
> The method startSharedConfigurationService hands off to a thread to load 
> cluster config and use distributed lock service to become primary cluster 
> config source. This was probably made async due to use of distributed lock 
> service to keep startup responsive. Unfortunately, it opens up a race 
> condition window -- if any requests come in before cluster config is ready, 
> the locator will reply saying it doesn't have cluster config. I think some of 
> our Flaky tests are hitting this race condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Dan Smith (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768466#comment-15768466
 ] 

Dan Smith commented on GEODE-2238:
--

Even with my fix to the  changes, I saw GEODE-1976 happen in my precheckin. 
Looking at the logs, I see the same log message about "No locator(s) found with 
cluster configuration service."

Digging a little deeper, I think my earlier fix is incomplete. I found this 
code in StartupMessageReplyProcessor. I think this means that as soon as one 
member replies to the startup message, we will stop waiting. So we have this 
same problem where the member startup will continue on and get to 
GemfireCacheImpl.requestSharedConfiguration before we get the hosted locator 
information from the StartupResponseWithVersionMessage.

{code}
  /**
   * overridden from ReplyProcessor21 to allow early-out. If an existing member 
accepted or rejected
   * us then we are done.
   */
  @Override
  protected boolean canStopWaiting() {
return this.receivedAcceptance || this.receivedRejectionMessage;
  }
{code}

> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Dan Smith
>  Labels: Flaky
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2243) Modify path to spotless formatter

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768407#comment-15768407
 ] 

ASF subversion and git services commented on GEODE-2243:


Commit c1998d7398b837ee1e699bfd1952719443045d71 in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c1998d7 ]

GEODE-2243: Adjust path of spotless formatter

- This allows projects which depend on Geode to use Geode's formatter

Signed-off-by: Scott Jewell 


> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1943) CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9

[Jason Huynh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Huynh resolved GEODE-1943.

   Resolution: Fixed
Fix Version/s: 1.1.0

> CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9
> -
>
> Key: GEODE-1943
> URL: https://issues.apache.org/jira/browse/GEODE-1943
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Bruce Schuchardt
>Assignee: Jason Huynh
>  Labels: ci
> Fix For: 1.1.0
>
>
> Error Message
> java.lang.AssertionError: expected: but was:
> Stacktrace
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testInvalidateSession9(SessionReplicationIntegrationJUnitTest.java:817)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:59)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:32)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Resolved] (GEODE-2205) Race condition in startup of ConcurrentSerialGatewaySenderProcessor

[Jason Huynh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Huynh resolved GEODE-2205.

   Resolution: Fixed
Fix Version/s: 1.1.0

Was introduced and fixed before 1.1 has released

> Race condition in startup of ConcurrentSerialGatewaySenderProcessor
> ---
>
> Key: GEODE-2205
> URL: https://issues.apache.org/jira/browse/GEODE-2205
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> ConcurrentSerialGatewayEventSenderProcessor spins up the individual 
> SerialGatewayEventSenderProcessors.  During this time, the individual 
> processors will call waitForPrimary on the GatewaySenderAdvisor.  The advisor 
> uses the stopped flag from ConcurrentSerialGatewayEventSenderProcessor, which 
> starts off as false (only set to true after all Serial processors are 
> started).  
> This is where the timing issue arises.  If the serial processors start up and 
> the GatewaySenderAdvisor uses the flag from the Concurrent processor, the 
> serial senders will breaks out of the loop for waitingForPrimary and then 
> tries to handle failover.  The Concurrent processor eventually sets it's flag 
> to true and everything continues to run.
> If the serial processor was not a primary, it stays as a secondary and is in 
> a weird state where anything enqueued will throw an assert error.
> This issue began due to  changes in GEODE-2107: 
> c4ae846aa1689e2c5659b6ecc17e38689dd93976 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-1943) CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9

[Jason Huynh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Huynh reassigned GEODE-1943:
--

Assignee: Jason Huynh

> CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9
> -
>
> Key: GEODE-1943
> URL: https://issues.apache.org/jira/browse/GEODE-1943
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Bruce Schuchardt
>Assignee: Jason Huynh
>  Labels: ci
> Fix For: 1.1.0
>
>
> Error Message
> java.lang.AssertionError: expected: but was:
> Stacktrace
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testInvalidateSession9(SessionReplicationIntegrationJUnitTest.java:817)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:59)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:32)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Created] (GEODE-2243) Modify path to spotless formatter

[Jens Deppe (JIRA)]

Jens Deppe created GEODE-2243:
-

 Summary: Modify path to spotless formatter
 Key: GEODE-2243
 URL: https://issues.apache.org/jira/browse/GEODE-2243
 Project: Geode
  Issue Type: Improvement
  Components: build
Reporter: Jens Deppe


Modify path to spotless formatter xml slightly so that it can be used from 
closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2243) Modify path to spotless formatter

[Jens Deppe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe reassigned GEODE-2243:
-

Assignee: Jens Deppe

> Modify path to spotless formatter
> -
>
> Key: GEODE-2243
> URL: https://issues.apache.org/jira/browse/GEODE-2243
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Modify path to spotless formatter xml slightly so that it can be used from 
> closed side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2205) Race condition in startup of ConcurrentSerialGatewaySenderProcessor

[Jason Huynh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768402#comment-15768402
 ] 

Jason Huynh commented on GEODE-2205:


Commit as 164f04fbd85f20de6c7f9edef267d3f48463a954 
Was committed with incorrect jira number of GEODE-2215.  Should have been 
GEODE-2205

Commit 164f04fbd85f20de6c7f9edef267d3f48463a954 in geode's branch 
refs/heads/develop from Jason Huynh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=164f04f ]
GEODE-2215: GatewaySenderAdvisor checks the current processor to see if it has 
started
Previously it was checking the top level sender (possibly a concurrent sendor)
This allowed a race condition where the top level sender was still starting up
but the individual processors were ready to process. They would check the flag
and because the sender was not ready, the processors would act and start 
initiating
failover, which left the processor in a very weird state

> Race condition in startup of ConcurrentSerialGatewaySenderProcessor
> ---
>
> Key: GEODE-2205
> URL: https://issues.apache.org/jira/browse/GEODE-2205
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> ConcurrentSerialGatewayEventSenderProcessor spins up the individual 
> SerialGatewayEventSenderProcessors.  During this time, the individual 
> processors will call waitForPrimary on the GatewaySenderAdvisor.  The advisor 
> uses the stopped flag from ConcurrentSerialGatewayEventSenderProcessor, which 
> starts off as false (only set to true after all Serial processors are 
> started).  
> This is where the timing issue arises.  If the serial processors start up and 
> the GatewaySenderAdvisor uses the flag from the Concurrent processor, the 
> serial senders will breaks out of the loop for waitingForPrimary and then 
> tries to handle failover.  The Concurrent processor eventually sets it's flag 
> to true and everything continues to run.
> If the serial processor was not a primary, it stays as a secondary and is in 
> a weird state where anything enqueued will throw an assert error.
> This issue began due to  changes in GEODE-2107: 
> c4ae846aa1689e2c5659b6ecc17e38689dd93976 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2215) NPE in ViewCreator thread setting public keys into a NetView

[Jason Huynh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768399#comment-15768399
 ] 

Jason Huynh commented on GEODE-2215:


Sorry, I had the wrong jira number with this commit.  Please ignore the commit 
164f04fbd85f20de6c7f9edef267d3f48463a954 for this ticket.

> NPE in ViewCreator thread setting public keys into a NetView
> 
>
> Key: GEODE-2215
> URL: https://issues.apache.org/jira/browse/GEODE-2215
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> I saw an NPE in a ViewCreator thread and created this unit test to reproduce 
> the problem:
> {code}
>   public void testNullPublicKeysNotRetained() throws Exception {
> NetView view = new NetView(members.get(0), 2, new ArrayList<>(members));
> setFailureDetectionPorts(view);
> NetView newView = new NetView(view, 3);
> for (InternalDistributedMember member: view.getMembers()) {
>   view.setPublicKey(member, null);
> }
> newView.setPublicKeys(view);
> for (InternalDistributedMember member: view.getMembers()){
>   assertNull(newView.getPublicKey(member));
>   assertNull(view.getPublicKey(member));
> }
>   }
> {code}
> The problem seems to be that some Maps that NetView uses to hold these keys 
> accept null values whlie others do not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Jinmei Liao]

> On Dec. 21, 2016, 8:52 p.m., Bruce Schuchardt wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java,
> >  line 743
> > 
> >
> > I can't tell from the diff if this method is rolling-upgrade safe.  If 
> > it's just used during jar deployment then there's no problem.  If it's used 
> > during locator start-up then it will not work during rolling upgrade and 
> > backward-compatibility needs to be addressed.
> > 
> > If it's just used during jar deployment then you can ignore this 
> > comment.
> 
> Jinmei Liao wrote:
> This is used in locator start-up. So in rolling-upgrade scenario, we 
> would have a locator in 9.1 trying to start up and contacting locator in 9.0 
> which doesn't have this function?

In this case, we should be fine. Locator A before shutting down, should have 
all the deployed jars in its cluster_config directory, when it starts up with 
newer version, it shouldn't be trying to contact other locators to get the jars 
because all the deployed jars it knows of is already in it's working dir (it 
only goes to download jars from other locator when the jar is not in it's own 
file system).

This code is run when a new locator gets started up. we won't run into problems 
as long as we finish rolling upgrade all the existing locators before starting 
up new locator.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/#review159856
---


On Dec. 21, 2016, 6:16 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54943/
> ---
> 
> (Updated Dec. 21, 2016, 6:16 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
> Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * not to save the xml, properties in the file system, only in the internal 
> region.
> * the cc region's change listener is to download the jar from other locators
> 
> GEODE-2197: refactor cluster config and fix the test failures
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
>  3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  5e48d7ca0d9333b499fc5a9a9b0d4d67eff34856 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  a5302eac2389c88d4f2af7b6b0681ae149175287 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  8d4677357450b30eb460344571174b044251c5d6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
>  821e04b2c590bddd28b0727e504c6460d77cf709 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
>  2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
>  3af55874282d380e340874a24860fafad7ace126 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
>  c08ba924b652c05436f921c19d65392fd7f6859b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
>  4adf2110c4a270127adda1a5090d537a5e2de8c1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
>  605233fe69f68c04459dcd4b83cb71a2dc1b20c0 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/GetAllJarsFunction.java
>  0e50524bee26aaf78c8b11977b5d884b869548da 
>   
> geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
>  2777b152134c66d9dcc8e047d9d78c1253cf878a 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  f406d51ca467cd21321a0dfa19cffa832770171d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  63c88dd1aa521a6781a8e07567df661cd42fb6f7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  c135f3d9b3370b4a756a2c7688530c63a4e06d77 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  cfcbeed86ade004eb305d9a01d6fb128132a21ac 
>   
> 

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Mark Bretl (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768352#comment-15768352
 ] 

Mark Bretl commented on GEODE-2232:
---

I would vote for removing product names from class names as well. I think the 
addition of product names came from the history and the 'sharing' of code 
between products.
 
This seems to be a bigger topic and should be discussed on the dev list.

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-165) Add build support for generating antlr classes from grammar

[Mark Bretl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Bretl updated GEODE-165:
-
Assignee: Avinash Dongre  (was: Mark Bretl)

> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Avinash Dongre
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768336#comment-15768336
 ] 

ASF GitHub Bot commented on GEODE-165:
--

Github user scmbuildguy commented on the issue:

https://github.com/apache/geode/pull/322
  
+1 - I agree with generating these files should be done at build time and 
not checked into source. 


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Mark Bretl
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode issue #322: [GEODE-165] Fix for Add build support for generating antlr...

[scmbuildguy]

Github user scmbuildguy commented on the issue:

https://github.com/apache/geode/pull/322
  
+1 - I agree with generating these files should be done at build time and 
not checked into source. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768328#comment-15768328
 ] 

Darrel Schneider commented on GEODE-2232:
-

In addition to the exceptions listed we also have the interface GemFireCache.
I'd also vote for not changing "gemfire" to "geode". I think it would be best 
to no longer have the product name in class names.


> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768317#comment-15768317
 ] 

Darrel Schneider commented on GEODE-2232:
-

I think this would causes issues with being backwards compatible with version 
1.0.
I'm assigning this to Bruce because he recently worked on the compatibility 
issues caused by package renaming.


> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2232:

Assignee: Bruce Schuchardt

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2232:

Component/s: (was: core)

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dor
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 54948: fix unsafe concurrent mods on expiredTombstones ArrayList

[Darrel Schneider]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54948/
---

Review request for geode and anilkumar gingade.


Bugs: GEODE-2240
https://issues.apache.org/jira/browse/GEODE-2240


Repository: geode


Description
---

when adding to the expiredTombstones ArrayList the code now holds a sync on 
getBlockGCLock.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/TombstoneService.java 
2840134a5466a6bd4552ead334645889d761ce88 

Diff: https://reviews.apache.org/r/54948/diff/


Testing
---

precheckin


Thanks,

Darrel Schneider

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768252#comment-15768252
 ] 

ASF GitHub Bot commented on GEODE-165:
--

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/322
  
@agingade  - Yeah, they'll get generated every time you do a clean followed 
a by a build. Presumably if you don't do a clean the antlr plugin will detect 
if the files are up to date.

Prior to this fix I don't think there was even a README on how to generate 
these files. This fix is really the ideal solution - generated files should 
never be checked in to the source. This way everyone knows they need to modify 
oql.g, and everyone knows how to generate the resulting files because it 
happens automatically as part of the build.


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Mark Bretl
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode issue #322: [GEODE-165] Fix for Add build support for generating antlr...

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/322
  
@agingade  - Yeah, they'll get generated every time you do a clean followed 
a by a build. Presumably if you don't do a clean the antlr plugin will detect 
if the files are up to date.

Prior to this fix I don't think there was even a README on how to generate 
these files. This fix is really the ideal solution - generated files should 
never be checked in to the source. This way everyone knows they need to modify 
oql.g, and everyone knows how to generate the resulting files because it 
happens automatically as part of the build.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Bruce Schuchardt]

If it's used at startup you could have this happen:

   Locator A running 1.0.0
   Locator B running 1.0.0
   Server R running 1.0.0
   Server S running 1.0.0


In a rolling upgrade Locators are rolled to the new version first, one 
by one.


   Locator B running 1.0.0
   Server R running 1.0.0
   Server S running 1.0.0
   Locator A (restarted) running 1.1.0

Here Locator A would bootstrap from old-version Locator B.

In order for your change to work all locators would have to be stopped 
at the same time and then restarted.



Le 12/21/2016 à 1:03 PM, Jinmei Liao a écrit :



On Dec. 21, 2016, 8:52 p.m., Bruce Schuchardt wrote:

geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java,
 line 743


 I can't tell from the diff if this method is rolling-upgrade safe.  If 
it's just used during jar deployment then there's no problem.  If it's used 
during locator start-up then it will not work during rolling upgrade and 
backward-compatibility needs to be addressed.
 
 If it's just used during jar deployment then you can ignore this comment.

This is used in locator start-up. So in rolling-upgrade scenario, we would have 
a locator in 9.1 trying to start up and contacting locator in 9.0 which doesn't 
have this function?


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/#review159856
---


On Dec. 21, 2016, 6:16 p.m., Jinmei Liao wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/
---

(Updated Dec. 21, 2016, 6:16 p.m.)


Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
Duling, and Kirk Lund.


Repository: geode


Description
---

* not to save the xml, properties in the file system, only in the internal 
region.
* the cc region's change listener is to download the jar from other locators

GEODE-2197: refactor cluster config and fix the test failures


Diffs
-

   
geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
 3119823d6b8886cf893fd38ed58ca90b0c28eeb5
   
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 5e48d7ca0d9333b499fc5a9a9b0d4d67eff34856
   
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 a5302eac2389c88d4f2af7b6b0681ae149175287
   
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
 8d4677357450b30eb460344571174b044251c5d6
   
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
 821e04b2c590bddd28b0727e504c6460d77cf709
   
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
 2ddeda69177b2aea41ee1d1318d8fdb19324a20b
   
geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
 3af55874282d380e340874a24860fafad7ace126
   
geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
 c08ba924b652c05436f921c19d65392fd7f6859b
   
geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
 4adf2110c4a270127adda1a5090d537a5e2de8c1
   
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
 605233fe69f68c04459dcd4b83cb71a2dc1b20c0
   
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/GetAllJarsFunction.java
 0e50524bee26aaf78c8b11977b5d884b869548da
   
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 2777b152134c66d9dcc8e047d9d78c1253cf878a
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 f406d51ca467cd21321a0dfa19cffa832770171d
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 63c88dd1aa521a6781a8e07567df661cd42fb6f7
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 c135f3d9b3370b4a756a2c7688530c63a4e06d77
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 cfcbeed86ade004eb305d9a01d6fb128132a21ac
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ConfigGroup.java
 971f66751505b57a98d07b8680873a249d92a30d
   
geode-core/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationDUnitTest.java
 

[jira] [Created] (GEODE-2242) Destroy operations on PRELOADED regions are not applied in the receiving WAN site

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2242:


 Summary: Destroy operations on PRELOADED regions are not applied 
in the receiving WAN site
 Key: GEODE-2242
 URL: https://issues.apache.org/jira/browse/GEODE-2242
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Barry Oglesby


In the receiving site, all the processing in 
AbstractRegionEntry.processGatewayTag fails for the destroy event, a 
ConcurrentCacheModificationException is thrown, and the destroy event is not 
applied.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2242) Destroy operations on PRELOADED regions are not applied in the receiving WAN site

[Barry Oglesby (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barry Oglesby reassigned GEODE-2242:


Assignee: Barry Oglesby

> Destroy operations on PRELOADED regions are not applied in the receiving WAN 
> site
> -
>
> Key: GEODE-2242
> URL: https://issues.apache.org/jira/browse/GEODE-2242
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> In the receiving site, all the processing in 
> AbstractRegionEntry.processGatewayTag fails for the destroy event, a 
> ConcurrentCacheModificationException is thrown, and the destroy event is not 
> applied.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Bruce Schuchardt]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/#review159856
---



I don't know much about shared-configuration code but I looked through the diff 
and have one comment.


geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
 (line 635)


I can't tell from the diff if this method is rolling-upgrade safe.  If it's 
just used during jar deployment then there's no problem.  If it's used during 
locator start-up then it will not work during rolling upgrade and 
backward-compatibility needs to be addressed.

If it's just used during jar deployment then you can ignore this comment.


- Bruce Schuchardt


On Dec. 21, 2016, 6:16 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54943/
> ---
> 
> (Updated Dec. 21, 2016, 6:16 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
> Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * not to save the xml, properties in the file system, only in the internal 
> region.
> * the cc region's change listener is to download the jar from other locators
> 
> GEODE-2197: refactor cluster config and fix the test failures
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
>  3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  5e48d7ca0d9333b499fc5a9a9b0d4d67eff34856 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  a5302eac2389c88d4f2af7b6b0681ae149175287 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
>  8d4677357450b30eb460344571174b044251c5d6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
>  821e04b2c590bddd28b0727e504c6460d77cf709 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
>  2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
>  3af55874282d380e340874a24860fafad7ace126 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
>  c08ba924b652c05436f921c19d65392fd7f6859b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
>  4adf2110c4a270127adda1a5090d537a5e2de8c1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
>  605233fe69f68c04459dcd4b83cb71a2dc1b20c0 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/GetAllJarsFunction.java
>  0e50524bee26aaf78c8b11977b5d884b869548da 
>   
> geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
>  2777b152134c66d9dcc8e047d9d78c1253cf878a 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  f406d51ca467cd21321a0dfa19cffa832770171d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  63c88dd1aa521a6781a8e07567df661cd42fb6f7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  c135f3d9b3370b4a756a2c7688530c63a4e06d77 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  cfcbeed86ade004eb305d9a01d6fb128132a21ac 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ConfigGroup.java
>  971f66751505b57a98d07b8680873a249d92a30d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationDUnitTest.java
>  675f5fe25c560fdcccfeb493c759320d12b64caf 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
>  d6b770f6c9b18e8c090045a66864a027f0ad8062 
> 
> Diff: https://reviews.apache.org/r/54943/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768129#comment-15768129
 ] 

ASF GitHub Bot commented on GEODE-165:
--

Github user agingade commented on the issue:

https://github.com/apache/geode/pull/322
  
Earlier the files used to be generated when the grammar files are changed 
(which was a rare case); with this change are we generating the files, every 
time when the build/compilation is done?


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Mark Bretl
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768124#comment-15768124
 ] 

ASF GitHub Bot commented on GEODE-2109:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/296


> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #296: GEODE-2109 : Calling submit on ExecutionService can...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/296


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768122#comment-15768122
 ] 

ASF subversion and git services commented on GEODE-2109:


Commit eba189bb134dc6f00629492b4a5c00b392b9aa45 in geode's branch 
refs/heads/develop from [~deepak.dixit]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=eba189b ]

GEODE-2109: Replacing ExecutorService.submit calls with ExecutorService.execute 
call.

This will allow exceptions from those threads to be logged.

Refactored DiskStore task for delayed writes, we cannot replace
expensive writes tasks submit call with execute as later we check if
write call is completed or not.  Replaced submit call by execute in case
of DiskStore tasks like compactions, creating KRF's.

Replaced submit call for GIITask and RemoveMember tasks. GIITask is used
when adding member or starting managing activity when node becomes
managing node. While adding member we can make the
ExecutorService.execute call. Did not change the call for GIITask when
invoked from managing activity as possible exception is handled.

Added LoggingThreadGroup for SingleHopClientExecutor

This closes #296


> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2215) NPE in ViewCreator thread setting public keys into a NetView

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768102#comment-15768102
 ] 

ASF subversion and git services commented on GEODE-2215:


Commit 164f04fbd85f20de6c7f9edef267d3f48463a954 in geode's branch 
refs/heads/develop from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=164f04f ]

GEODE-2215: GatewaySenderAdvisor checks the current processor to see if it has 
started

  * Previously it was checking the top level sender (possibly a concurrent 
sendor)
  * This allowed a race condition where the top level sender was still starting 
up
  * but the individual processors were ready to process.  They would check the 
flag
  * and because the sender was not ready, the processors would act and start 
initiating
  * failover, which left the processor in a very weird state


> NPE in ViewCreator thread setting public keys into a NetView
> 
>
> Key: GEODE-2215
> URL: https://issues.apache.org/jira/browse/GEODE-2215
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> I saw an NPE in a ViewCreator thread and created this unit test to reproduce 
> the problem:
> {code}
>   public void testNullPublicKeysNotRetained() throws Exception {
> NetView view = new NetView(members.get(0), 2, new ArrayList<>(members));
> setFailureDetectionPorts(view);
> NetView newView = new NetView(view, 3);
> for (InternalDistributedMember member: view.getMembers()) {
>   view.setPublicKey(member, null);
> }
> newView.setPublicKeys(view);
> for (InternalDistributedMember member: view.getMembers()){
>   assertNull(newView.getPublicKey(member));
>   assertNull(view.getPublicKey(member));
> }
>   }
> {code}
> The problem seems to be that some Maps that NetView uses to hold these keys 
> accept null values whlie others do not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1943) CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768096#comment-15768096
 ] 

ASF subversion and git services commented on GEODE-1943:


Commit 225066b48c9fa0292df5454d3c3a32db113e6613 in geode's branch 
refs/heads/develop from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=225066b ]

GEODE-1943: Minor modification to test


> CI failure: SessionReplicationIntegrationJUnitTest.testInvalidateSession9
> -
>
> Key: GEODE-1943
> URL: https://issues.apache.org/jira/browse/GEODE-1943
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Bruce Schuchardt
>  Labels: ci
>
> Error Message
> java.lang.AssertionError: expected: but was:
> Stacktrace
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.modules.session.internal.filter.SessionReplicationIntegrationJUnitTest.testInvalidateSession9(SessionReplicationIntegrationJUnitTest.java:817)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:59)
>   at 
> org.apache.geode.modules.session.junit.NamedRunner.runChild(NamedRunner.java:32)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[GitHub] geode issue #296: GEODE-2109 : Calling submit on ExecutionService can cause ...

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/296
  
@deepakddixit - I think using LoggingThreadGroup is definitely a better 
fix. The changes look good to me now, I'll merge them. Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 54209: GEODE-1931: CI Failure: LocatorUDPSecurityDUnitTest.testStartTwoLocators

[Udo Kohlmeyer]

> On Nov. 30, 2016, 6:49 p.m., Bruce Schuchardt wrote:
> > I don't see anything wrong here - lots of improvements.  Was there anything 
> > that you corrected in the test other than getting rid of pauses and 
> > WaitCriteria?  How about running the test a few hundred times before 
> > checking it in?

Correct. Lots of small improvements. I ran the test over 100 times without any 
failure.


- Udo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54209/#review157432
---


On Nov. 30, 2016, 5:20 p.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54209/
> ---
> 
> (Updated Nov. 30, 2016, 5:20 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Hitesh Khamesra.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Refactored the LocatorDUnitTest and LocatorUDPSecurityDUnitTest to best match 
> our new practices with Lambdas and Awaitility blocks rather than Wait.pause + 
> WaitCriterion
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 128f970 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  3246f85 
> 
> Diff: https://reviews.apache.org/r/54209/diff/
> 
> 
> Testing
> ---
> 
> Precheckin - completed
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

[jira] [Created] (GEODE-2241) gfsh lucene will generate duplicate results

[xiaojian zhou (JIRA)]

xiaojian zhou created GEODE-2241:


 Summary: gfsh lucene will generate duplicate results
 Key: GEODE-2241
 URL: https://issues.apache.org/jira/browse/GEODE-2241
 Project: Geode
  Issue Type: Bug
Reporter: xiaojian zhou


When started 2 servers, run gfsh will always display duplicated results.

The root cause is: we submit a function call to execute query on each member.

gfsh>list lucene indexes
 Index Name   | Region Path |   Indexed Fields   |Field Analyzer
| Status
- | --- | -- |  
| ---
analyzerIndex | /Person | [address, name, email] | {address=MyCharact.. 
| Initialized
analyzerIndex | /Person | [address, name, email] | {address=MyCharact.. 
| Initialized
customerIndex | /Customer   | [symbol, revenue, SSN, n.. | {}   
| Initialized
customerIndex | /Customer   | [symbol, revenue, SSN, n.. | {}   
| Initialized
pageIndex | /Page   | [symbol, name, email, ad.. | {}   
| Initialized
pageIndex | /Page   | [symbol, name, email, ad.. | {}   
| Initialized
personIndex   | /Person | [name, email, address, s.. | {}   
| Initialized
personIndex   | /Person | [name, email, address, s.. | {}   
| Initialized

gfsh>search lucene --name=personIndex --region=/Person --defaultField=name 
--queryStrings="Tom*JSON"
  key|value 
   | score
 | 
--- | 
-
jsondoc1 | PDX[3,__GEMFIRE_JSON]{address=PDX[1,__GEMFIRE_JSON]{city=New York, 
postal.. | 1
jsondoc2 | PDX[3,__GEMFIRE_JSON]{address=PDX[1,__GEMFIRE_JSON]{city=New York, 
postal.. | 1
jsondoc1 | PDX[3,__GEMFIRE_JSON]{address=PDX[1,__GEMFIRE_JSON]{city=New York, 
postal.. | 1
jsondoc2 | PDX[3,__GEMFIRE_JSON]{address=PDX[1,__GEMFIRE_JSON]{city=New York, 
postal.. | 1




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 54945: GEODE-419: Added test to test fail over to javax properties if ssl enabled but relevant properties are not set

[Udo Kohlmeyer]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54945/
---

Review request for geode, Bruce Schuchardt and Kirk Lund.


Repository: geode


Description
---

If ssl is enabled but neither ssl-keystore or cluster-ssl-keystore properties 
are set, the ssl configuration behavior should be to fail over to javas 
properties (if provided). This seemed not to work in the previous ssl 
configuration implementation, but seems to be now fixed in the newer 
SSLConfiguration implementation.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/net/SSLConfigurationFactory.java
 aa61ca36e 
  
geode-core/src/test/java/org/apache/geode/internal/net/SSLConfigurationFactoryJUnitTest.java
 38d4d87b3 

Diff: https://reviews.apache.org/r/54945/diff/


Testing
---

Added test to test scenario. No code was changed for this.


Thanks,

Udo Kohlmeyer

[jira] [Commented] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767845#comment-15767845
 ] 

Darrel Schneider commented on GEODE-2240:
-

I think this bug might be caused by the code that adds to "expiredTombstones", 
TombstoneService.ReplicateTombstoneSweeper.expireTombstone, not syncing on 
getBlockGCLock() as the code that removes from "expiredTomstones", 
TombstoneService.ReplicateTombstoneSweeper.removeExpiredIf, does.
Since these are the only two methods that modify the "expiredTombstones" 
collection they need a common sync to prevent unsafe concurrent modification of 
the ArrayList.
I think the only time multiple threads would do this concurrently is when a 
region is being destroyed.


> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-165) Add build support for generating antlr classes from grammar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767804#comment-15767804
 ] 

ASF GitHub Bot commented on GEODE-165:
--

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/322
  
Yeah, I think it's good to go.


> Add build support for generating antlr classes from grammar
> ---
>
> Key: GEODE-165
> URL: https://issues.apache.org/jira/browse/GEODE-165
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Mark Bretl
>
> The OQL engine currently uses antlr to generate some parsing classes from 
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/oql.g
> These are the generated classes. They are currently checked into the source.
> OQLLexer.java
> OQLLexerTokenTypes.java
> OQLLexerTokenTypes.txt
> OQLParser.java
> They can be generated manually by running antlr.Tool on the provided grammar.
> cd gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/parse/
> java -cp antlr.jar antlr.Tool oql.g
> We should add support to the gradle build to generate these classes.
> In my opinion we should also remove the checked in classes. With gradle we 
> can configure things so that the gradle eclipse target will generate these 
> classes and make them available to the IDE as well. Look at 
> gemfire-core/build.gradle for how we do this with the version properties file:
> sourceSets {
>   main {
> output.dir(generatedResources, builtBy: 'createVersionPropertiesFile')
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2240:
---

 Summary: unexpected NullPointerException from Tombstone service
 Key: GEODE-2240
 URL: https://issues.apache.org/jira/browse/GEODE-2240
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Darrel Schneider


A test failed and the logs were found to be full of NPEs from the tombstone 
service:[severe 2016/12/20 02:04:35.605 UTC 
dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
 tid=0x44] GemFire garbage 
collection service encountered an unexpected exception
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
at java.lang.Thread.run(Thread.java:745)

[severe 2016/12/20 02:05:45.987 UTC 
dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
 tid=0x44] GemFire garbage 
collection service encountered an unexpected exception
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
at java.lang.Thread.run(Thread.java:745)

Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
has nulls in it. It is an ArrayList of Tombstone instances and the only code 
that adds to it first tests that the item it is adding is not null. The only 
other modify operation done on it is to remove an item.
Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: snappy-java dependency version

[Dan Smith]

We switched to org.iq80.snappy because that's a pure java implementation,
as opposed to just a wrapper around the C++ implementation. See GEODE-1573
 for some details.

I'm kinda surprised it doesn't work on Solaris. We switched to the new
version to avoid these sort of cross platform compatibility issues. How is
it failing on Solaris?

Here's the github page for this new snappy implementation:
https://github.com/dain/snappy/

-Dan

On Wed, Dec 21, 2016 at 9:40 AM, Kirk Lund  wrote:

> More info: I'm looking at the snappy dependency in Apache Geode because a
> user reported that SnappyCompressor in Apache 1.0.0-incubating doesn't work
> on Solaris x86.
>
> Hmm, I see that Geode uses org.iq80.snappy (latest version is 0.4):
>
> org.iq80.snappy:snappy:0.4
>
> Previous versions of GemFire used org.xerial.snappy (latest version is
> 1.1.2.6):
>
> org.xerial.snappy:snappy-java:1.0.4.1
>
> Additional questions:
>
> Do we know why we changed from org.xerial.snappy to org.iq80.snappy? Was
> this change made because org.xerial.snappy is not compatible with Apache
> licenses? And does this change the platforms that SnappyCompressor will
> work on?
>
> Thanks,
> Kirk
>
>
> On Wed, Dec 21, 2016 at 9:28 AM, Kirk Lund  wrote:
>
> > I'm looking at gradle/dependency-versions.properties and I'm not sure
> the
> > snappy-java.version is correct:
> >
> > snappy-java.version=0.4
> >
> > 0.4 would be a very old version. GemFire 8.x uses 1.0.4.1:
> >
> > 
> > 
> >
> > Anyone know why it would be set to 0.4 in Geode? Or is 0.4 some weird
> > alias for 1.0.4.1??
> >
> > Thanks,
> > Kirk
> >
> >
>

Re: Review Request 54943: GEODE-2197: refactor cluster config

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/
---

(Updated Dec. 21, 2016, 6:16 p.m.)


Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
Duling, and Kirk Lund.


Repository: geode


Description
---

* not to save the xml, properties in the file system, only in the internal 
region.
* the cc region's change listener is to download the jar from other locators

GEODE-2197: refactor cluster config and fix the test failures


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
 3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 5e48d7ca0d9333b499fc5a9a9b0d4d67eff34856 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 a5302eac2389c88d4f2af7b6b0681ae149175287 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
 8d4677357450b30eb460344571174b044251c5d6 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
 821e04b2c590bddd28b0727e504c6460d77cf709 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
 2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
 3af55874282d380e340874a24860fafad7ace126 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
 c08ba924b652c05436f921c19d65392fd7f6859b 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
 4adf2110c4a270127adda1a5090d537a5e2de8c1 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
 605233fe69f68c04459dcd4b83cb71a2dc1b20c0 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/GetAllJarsFunction.java
 0e50524bee26aaf78c8b11977b5d884b869548da 
  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 2777b152134c66d9dcc8e047d9d78c1253cf878a 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 f406d51ca467cd21321a0dfa19cffa832770171d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 63c88dd1aa521a6781a8e07567df661cd42fb6f7 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 c135f3d9b3370b4a756a2c7688530c63a4e06d77 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 cfcbeed86ade004eb305d9a01d6fb128132a21ac 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ConfigGroup.java
 971f66751505b57a98d07b8680873a249d92a30d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationDUnitTest.java
 675f5fe25c560fdcccfeb493c759320d12b64caf 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
 d6b770f6c9b18e8c090045a66864a027f0ad8062 

Diff: https://reviews.apache.org/r/54943/diff/


Testing (updated)
---

precheckin successful


Thanks,

Jinmei Liao

Review Request 54943: GEODE-2197: refactor cluster config

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54943/
---

Review request for geode, Bruce Schuchardt, Jared Stewart, John Blum, Kevin 
Duling, and Kirk Lund.


Repository: geode


Description
---

* not to save the xml, properties in the file system, only in the internal 
region.
* the cc region's change listener is to download the jar from other locators

GEODE-2197: refactor cluster config and fix the test failures


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
 3119823d6b8886cf893fd38ed58ca90b0c28eeb5 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 5e48d7ca0d9333b499fc5a9a9b0d4d67eff34856 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 a5302eac2389c88d4f2af7b6b0681ae149175287 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
 8d4677357450b30eb460344571174b044251c5d6 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
 821e04b2c590bddd28b0727e504c6460d77cf709 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
 2ddeda69177b2aea41ee1d1318d8fdb19324a20b 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
 3af55874282d380e340874a24860fafad7ace126 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/callbacks/ConfigurationChangeListener.java
 c08ba924b652c05436f921c19d65392fd7f6859b 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/Configuration.java
 4adf2110c4a270127adda1a5090d537a5e2de8c1 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
 605233fe69f68c04459dcd4b83cb71a2dc1b20c0 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/GetAllJarsFunction.java
 0e50524bee26aaf78c8b11977b5d884b869548da 
  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 2777b152134c66d9dcc8e047d9d78c1253cf878a 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 f406d51ca467cd21321a0dfa19cffa832770171d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 63c88dd1aa521a6781a8e07567df661cd42fb6f7 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 c135f3d9b3370b4a756a2c7688530c63a4e06d77 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 cfcbeed86ade004eb305d9a01d6fb128132a21ac 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ConfigGroup.java
 971f66751505b57a98d07b8680873a249d92a30d 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationDUnitTest.java
 675f5fe25c560fdcccfeb493c759320d12b64caf 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
 d6b770f6c9b18e8c090045a66864a027f0ad8062 

Diff: https://reviews.apache.org/r/54943/diff/


Testing
---


Thanks,

Jinmei Liao

[jira] [Updated] (GEODE-2239) CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs

[Bruce Schuchardt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruce Schuchardt updated GEODE-2239:

Labels: ci flaky  (was: )

> CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
> -
>
> Key: GEODE-2239
> URL: https://issues.apache.org/jira/browse/GEODE-2239
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Bruce Schuchardt
>  Labels: ci, flaky
>
> This test failed in Jenkins build #692.  It has a hard-coded port 40405 and 
> fails if the port isn't available.  
> https://builds.apache.org/job/Geode-nightly/692/testReport/
> {noformat}
>  org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
>  Error Details
> java.net.BindException: Failed to create server socket on  null[40,405]
>  Stack Trace
> java.net.BindException: Failed to create server socket on  null[40,405]
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:744)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:711)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:436)
>   at 
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:318)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.setUp(JSONFormatterJUnitTest.java:59)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 

[jira] [Resolved] (GEODE-1893) remove ability to create a locator without all location services

[Bruce Schuchardt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruce Schuchardt resolved GEODE-1893.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> remove ability to create a locator without all location services
> 
>
> Key: GEODE-1893
> URL: https://issues.apache.org/jira/browse/GEODE-1893
> Project: Geode
>  Issue Type: Wish
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> Both the API and DistributedSystem properties allow you to create a Locator 
> that has server or peer location services disabled.  These options should 
> never have been added and need to be removed.  A Locator should always start 
> all location services.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-77) Replace JGroups 2.2.9

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767359#comment-15767359
 ] 

ASF subversion and git services commented on GEODE-77:
--

Commit 65220a3f412311b7522727888985e51cc63e45e0 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=65220a3 ]

GEODE-77: Replace JGroups 2.2.9

This adds a test ensuring that a large membership ID is properly transmitted
via JGroups.  An older version of GemFire recently ran into this problem so
I wanted to make sure it works okay in Geode with its new membership services.


> Replace JGroups 2.2.9
> -
>
> Key: GEODE-77
> URL: https://issues.apache.org/jira/browse/GEODE-77
> Project: Geode
>  Issue Type: Bug
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Blocker
> Fix For: 1.0.0-incubating.M1
>
> Attachments: 
> GEODE-MembershipManagerFunctionalSpecification-130715-1604-29054.pdf
>
>
> The JGroups 2.2.9 sources that are currently included in Geode must be 
> replaced in order for Geode to leave incubation.  A wiki document has been 
> created to investigate alternatives.
> https://cwiki.apache.org/confluence/display/GEODE/Replacing+JGroups+2.2.9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1893) remove ability to create a locator without all location services

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767358#comment-15767358
 ] 

ASF subversion and git services commented on GEODE-1893:


Commit c33ce7db8148fe0b300066581f26582e3e044e96 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c33ce7d ]

GEODE-1893 remove ability to create a locator without all location services

Deprecated API options for creating a locator without peerLocation or
serverLocation handlers.  There will be documentation work to do since
the docs mention this in at least one place.


> remove ability to create a locator without all location services
> 
>
> Key: GEODE-1893
> URL: https://issues.apache.org/jira/browse/GEODE-1893
> Project: Geode
>  Issue Type: Wish
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> Both the API and DistributedSystem properties allow you to create a Locator 
> that has server or peer location services disabled.  These options should 
> never have been added and need to be removed.  A Locator should always start 
> all location services.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)