Re: User permissions for Galen O'Sullivan

[Mark Bretl]

Welcome Galen!

Looking forward to seeing more contributions!

--Mark

On Thu, Jan 5, 2017 at 4:48 PM, Kirk Lund  wrote:

> Welcome Galen!
>
>
> On Thu, Jan 5, 2017 at 2:00 PM, Galen M O'Sullivan 
> wrote:
>
> > Thanks, Mark! I suppose I'll add a brief introduction:
> >
> > Hi, I'm Galen O'Sullivan. I joined Pivotal fairly recently. I've
> previously
> > worked at New Relic and Coherent Logix. In my free time I've been playing
> > with Rust and the Ergodox (though not at the same time). I think it's
> > pretty awesome that I can get paid to work on open source software.
> >
> > Cheers!
> >
> > Galen
> >
> > On Thu, Jan 5, 2017 at 12:03 PM, Anthony Baker 
> wrote:
> >
> > > Thanks Mark.  I updated [1] with this process note.
> > >
> > > Anthony
> > >
> > > [1] https://cwiki.apache.org/confluence/display/GEODE/
> Developer+Workflow
> > >
> > > > On Jan 5, 2017, at 11:39 AM, Mark Bretl  wrote:
> > > >
> > > > Hi Udo (and Galen),
> > > >
> > > > I have added Galen to the Geode project in JIRA.
> > > >
> > > > For future reference, we highly encourage new contributors to ask for
> > > > themselves as a way of introducing themselves to the community. I
> think
> > > we
> > > > should add this 'instruction' to the Community page on the site [1]
> > > >
> > > > --Mark
> > > >
> > > > [1] http://geode.apache.org/community/
> > > >
> > > > On Thu, Jan 5, 2017 at 11:19 AM, Udo Kohlmeyer <
> ukohlme...@pivotal.io>
> > > > wrote:
> > > >
> > > >> Hi there,
> > > >>
> > > >> Can someone with the relevant powers and permissions add Galen
> > > O'Sullivan
> > > >> as a contributor in Apache Jira?
> > > >>
> > > >> --Udo
> > > >>
> > > >>
> > >
> > >
> >
>

[GitHub] geode pull request #313: [GEODE-1407] Change a FlakyTest to distributedTest.

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/313#discussion_r94888520
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java ---
@@ -534,41 +532,35 @@ public Object call() throws CacheException {
 Cache cache = getCache();
 Region myRegion = cache.getRegion("root/myRegion");
 myRegion.put("MyKey1", "MyValue1");
-// myRegion.put("Mykey2", "MyValue2");
 return savedSystem.getDistributedMember();
   }
 };
 vm1.invoke(create1);
 
-
 try {
-
   dm = getDMID(vm0);
   createGfshWaitingThread(vm0);
   forceDisconnect(vm0);
   newdm = waitForReconnect(vm0);
   assertGfshWaitingThreadAlive(vm0);
 
-  vm0.invoke(new SerializableRunnable("check for running locator") {
-public void run() {
-  WaitCriterion wc = new WaitCriterion() {
-public boolean done() {
-  return Locator.getLocator() != null;
-}
-
-public String description() {
-  return "waiting for locator to restart";
-}
-  };
-  Wait.waitForCriterion(wc, 3, 1000, false);
+  boolean running = (Boolean) vm0.invoke(new 
SerializableCallable("check for running locator") {
--- End diff --

Done, and I changed the rest of the method to be consistent.


---
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: User permissions for Galen O'Sullivan

[Kirk Lund]

Welcome Galen!


On Thu, Jan 5, 2017 at 2:00 PM, Galen M O'Sullivan 
wrote:

> Thanks, Mark! I suppose I'll add a brief introduction:
>
> Hi, I'm Galen O'Sullivan. I joined Pivotal fairly recently. I've previously
> worked at New Relic and Coherent Logix. In my free time I've been playing
> with Rust and the Ergodox (though not at the same time). I think it's
> pretty awesome that I can get paid to work on open source software.
>
> Cheers!
>
> Galen
>
> On Thu, Jan 5, 2017 at 12:03 PM, Anthony Baker  wrote:
>
> > Thanks Mark.  I updated [1] with this process note.
> >
> > Anthony
> >
> > [1] https://cwiki.apache.org/confluence/display/GEODE/Developer+Workflow
> >
> > > On Jan 5, 2017, at 11:39 AM, Mark Bretl  wrote:
> > >
> > > Hi Udo (and Galen),
> > >
> > > I have added Galen to the Geode project in JIRA.
> > >
> > > For future reference, we highly encourage new contributors to ask for
> > > themselves as a way of introducing themselves to the community. I think
> > we
> > > should add this 'instruction' to the Community page on the site [1]
> > >
> > > --Mark
> > >
> > > [1] http://geode.apache.org/community/
> > >
> > > On Thu, Jan 5, 2017 at 11:19 AM, Udo Kohlmeyer 
> > > wrote:
> > >
> > >> Hi there,
> > >>
> > >> Can someone with the relevant powers and permissions add Galen
> > O'Sullivan
> > >> as a contributor in Apache Jira?
> > >>
> > >> --Udo
> > >>
> > >>
> >
> >
>

[jira] [Assigned] (GEODE-2274) Need to add additional unit test coverage on non colocated transaction

[Eric Shu (JIRA)]

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

Eric Shu reassigned GEODE-2274:
---

Assignee: Eric Shu

> Need to add additional unit test coverage on non colocated transaction
> --
>
> Key: GEODE-2274
> URL: https://issues.apache.org/jira/browse/GEODE-2274
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Need to add additional entry operations on non colocated transaction and get 
> expected transaction exception.



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

[jira] [Updated] (GEODE-2273) Display the server name while listing the Lucene index stats

[nabarun (JIRA)]

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

nabarun updated GEODE-2273:
---
Description: 
Display the server's name hosting the Lucene indexes while listing the Lucene 
index stats in gfsh.
Currently we can't distinguish between the listed pairs.
{noformat}

gfsh>list lucene indexes --with-stats
   Index Name | Region Path |  Indexed Fields  | Field 
Analyzer |   Status| Query Executions | Updates | Commits | Documents
- | --- |  | 
-- | --- |  | --- | --- | -
customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {} 
| Initialized | 0| 0   | 0   | 0
customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {} 
| Initialized | 0| 0   | 0   | 0
{noformat}


  was:
Display the server's name hosting the Lucene indexes while listing the Lucene 
index stats in gfsh.
Currently we can't distinguish between the listed pairs.




> Display the server name while listing the Lucene index stats
> 
>
> Key: GEODE-2273
> URL: https://issues.apache.org/jira/browse/GEODE-2273
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Display the server's name hosting the Lucene indexes while listing the Lucene 
> index stats in gfsh.
> Currently we can't distinguish between the listed pairs.
> {noformat}
> 
> gfsh>list lucene indexes --with-stats
>Index Name | Region Path |  Indexed Fields  | Field 
> Analyzer |   Status| Query Executions | Updates | Commits | Documents
> - | --- |  | 
> -- | --- |  | --- | --- | 
> -
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> customerRegionAll | /customer   | [lastUpdateDateTime, displayNa.. | {}   
>   | Initialized | 0| 0   | 0   | 0
> {noformat}



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

[jira] [Created] (GEODE-2273) Display the server name while listing the Lucene index stats

[nabarun (JIRA)]

nabarun created GEODE-2273:
--

 Summary: Display the server name while listing the Lucene index 
stats
 Key: GEODE-2273
 URL: https://issues.apache.org/jira/browse/GEODE-2273
 Project: Geode
  Issue Type: Bug
Reporter: nabarun


Display the server's name hosting the Lucene indexes while listing the Lucene 
index stats in gfsh.
Currently we can't distinguish between the listed pairs.





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

[jira] [Updated] (GEODE-2272) Pulse Data Browser export hangs

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2272:
-
Affects Version/s: 1.0.0-incubating

> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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

[jira] [Assigned] (GEODE-2272) Pulse Data Browser export hangs

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2272:


Assignee: Jared Stewart

> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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

[jira] [Updated] (GEODE-2272) Pulse Data Browser export hangs

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2272:
-
Fix Version/s: 1.1.0

> Pulse Data Browser export hangs
> ---
>
> Key: GEODE-2272
> URL: https://issues.apache.org/jira/browse/GEODE-2272
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.0.0-incubating
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> The Export feature of Pulse Data Browser is prone to hang with large amounts 
> of data as it requires loading all the query results into the browser before 
> they can be exported.  Instead, we should allow a user to Export query 
> results directly to a file without first loading the results into their 
> browser.



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

[jira] [Created] (GEODE-2272) Pulse Data Browser export hangs

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2272:


 Summary: Pulse Data Browser export hangs
 Key: GEODE-2272
 URL: https://issues.apache.org/jira/browse/GEODE-2272
 Project: Geode
  Issue Type: Bug
  Components: pulse
Reporter: Jared Stewart


The Export feature of Pulse Data Browser is prone to hang with large amounts of 
data as it requires loading all the query results into the browser before they 
can be exported.  Instead, we should allow a user to Export query results 
directly to a file without first loading the results into their browser.



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

[jira] [Commented] (GEODE-2236) Attempting to remove all CacheListeners from a Region using gfsh throws NullPointerException

[ASF GitHub Bot (JIRA)]

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

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

Github user kjduling commented on the issue:

https://github.com/apache/geode/pull/327
  
+1


> Attempting to remove all CacheListeners from a Region using gfsh throws 
> NullPointerException
> 
>
> Key: GEODE-2236
> URL: https://issues.apache.org/jira/browse/GEODE-2236
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Assignee: Deepak Dixit
>
> The --cache-listener option to the alter region command replaces the existing 
> CacheListeners with the ones set in the option.
> What happens in RegionAlterFunction is that the existing CacheListeners not 
> included in the new list are removed, then the new ones are added.
> So, in theory, to remove all CacheListeners, an empty string could be passed 
> into the --cache-listener option like:
> {noformat}
> alter region --name=data --cache-listener=''
> Executing - alter region --name=data --cache-listener=""
> Member  | Status
> --- | 
> --
> server2 | ERROR: java.lang.NullPointerException
>   at com.gemstone.gemfire.manag..
> server1 | ERROR: java.lang.NullPointerException
>   at com.gemstone.gemfire.manag..
> {noformat}
> This actually works but it throws the NPE below.
> {noformat}
> [error 2016/09/13 09:48:59.943 PDT server1  
> tid=0x40] 
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.newInstance(RegionAlterFunction.java:320)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.alterRegion(RegionAlterFunction.java:228)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.execute(RegionAlterFunction.java:64)
>   at 
> com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:457)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:692)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1149)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> A work-around to this issue is to set a non-existent CacheListener in the 
> --cache-listener option like:
> {noformat}
> alter region --name=data --cache-listener=Fred
> Executing - alter region --name=data --cache-listener=Fred
> Member  | Status
> --- | --
> server1 | ERROR: Could not find class "Fred" specified for "cache-listener".
> server2 | ERROR: Could not find class "Fred" specified for "cache-listener".
> {noformat}
> This correctly throws the ClassNotFoundException below and also removes all 
> the existing CacheListeners.
> {noformat}
> [error 2016/09/13 09:46:40.537 PDT server1  
> tid=0x40] Could not find class "Fred" specified for "cache-listener".
> java.lang.RuntimeException: Could not find class "Fred" specified for 
> "cache-listener".
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.forName(RegionAlterFunction.java:306)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.alterRegion(RegionAlterFunction.java:227)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.execute(RegionAlterFunction.java:64)
>   at 
> com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:457)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:692)
>   at 
> 

[GitHub] geode issue #327: GEODE-2236: Remove all cache-listners using Gfsh

[kjduling]

Github user kjduling commented on the issue:

https://github.com/apache/geode/pull/327
  
+1


---
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: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Bruce Schuchardt]

Open your Gradle tool window and find the generateGrammarSources task 
under geode-core.  Get its pop-up menu and check "Execute before 
Build".  Bob's your uncle.



Le 1/5/2017 à 2:13 PM, John Blum a écrit :
@Dan- right.  There are only 2 options in IntelliJ.  1 way is with 
Annotation Processors; IntelliJ can search for processors on the 
classpath (i.e. based on the project's dependencies).  But as the name 
implies, it is a pre-processor for annotations in source code.  Think 
of something like Project Lombok  [1], a 
very useful tool in testing.


The other way is to define a (Antlr) module that the Geode modules 
depend on.  The dependency could be explicitly added in IntelliJ to 
geode-core module. The Antlr module could be built using the Gradle 
task defined in the Geode Gradle build.  However, this would get 
stomped every time someone re-imported the Gradle build files for Geode.


Probably the best option is as *Udo* described, or to first run a 
clean/build with Gradle, then build/test in IntelliJ (assuming IDEA 
does not blow away the build output on rebuilds).


Anyhow...


[1] https://projectlombok.org/


On Thu, Jan 5, 2017 at 1:46 PM, Udo Kohlmeyer > wrote:


Maybe you tell IntelliJ to use gradle rather than its internal
delegates.


On 1/5/17 13:35, Dan Smith wrote:

John - yes, there's a new gradle task. The task that needs run is
geode-core:generateGrammarSource. For eclipse, we made the eclipse task
depend on that task. If we can figure out how to get intellij to
automatically run that task that sounds like the way to go.

-Dan

On Thu, Jan 5, 2017 at 12:47 PM, Udo Kohlmeyer 

wrote:


In the newer IntelliJ you can actually have IntelliJ invoke the gradle
commands for build/run/build instead of its own internal implementation.

--Udo



On 1/5/17 12:45, John Blum wrote:


@Kirk - Is it part of a new (Gradle) build step to generate the Antlr
classes from source?  In which case, you can configure IntelliJ to perform
this step during compiling I believe.

On Thu, Jan 5, 2017 at 12:39 PM, Kirk Lund 
  wrote:

Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why

should a "./gradlew clean build" from command-line be required to get
IntelliJ to work?

-Kirk


On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer 

wrote:

I had the same problem. gradle clean build did the trick for me

On 12/27/16 13:45, Bruce Schuchardt wrote:

Actually neither refreshing from gradle nor creating a new Intellij

project worked.  I had to go to the "other" tasks under geode-core in


the
Gradle window and set "generateGrammarSource" to run before building.

Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :

Refreshing your project from gradle ought to work to. Eclipse users
will

probably need to run ./gradlew eclipse and refresh their eclipse

project.

There is a new generated-src directory that needs to be on the source

path.

-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt <
bschucha...@pivotal.io >
wrote:

I did a pull today on my Windows 7 laptop and my IntelliJ build
started


failing with compilation errors looking for "OQLLexerTokenTypes".


This

comes from the fix for GEODE-165. Refreshing the IntelliJ build

structure
picked up the antlr tasks needed to generate this and other OQL
source
files but IntelliJ would not execute them.

You either need to do a command-line build or close your IntelliJ
project
and import the gradle build into a new IntelliJ project.




--
-John
john.blum10101 (skype)

Re: OQLLexerTokenTypes - java: connot find symbol

[Kirk Lund]

That worked. Thanks everyone!


On Thu, Jan 5, 2017 at 12:47 PM, Kai Jiang  wrote:

> I agreed with Jason. This happened in my environment several times. Clean
> build could work.
>
> Best,
> Kai
>
> On Thu, Jan 5, 2017 at 12:39 PM, Jason Huynh  wrote:
>
> > I think a clean build and refreshing the intelij project should work.  I
> > think the change removed those files and requires them to be generated
> from
> > the build
> >
> > On Thu, Jan 5, 2017 at 12:36 PM Kirk Lund  wrote:
> >
> > > I rebased one of my feature branches on origin/develop, then refreshed
> > > gradle in IntelliJ and then rebuilt my IntelliJ project but IntelliJ
> > > insists that OQLLexerTokenTypes does not exist. My project is full of
> > > errors like this:
> > >
> > > Error:(29, 51) java: cannot find symbol
> > >   symbol:   class OQLLexerTokenTypes
> > >   location: package org.apache.geode.cache.query.internal.parse
> > >
> > > Any ideas how to get my IntelliJ project working again without losing
> too
> > > much time?
> > >
> > > Thanks,
> > > Kirk
> > >
> >
>

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[John Blum]

@Dan- right.  There are only 2 options in IntelliJ.  1 way is with
Annotation Processors; IntelliJ can search for processors on the classpath
(i.e. based on the project's dependencies).  But as the name implies, it is
a pre-processor for annotations in source code.  Think of something
like Project
Lombok  [1], a very useful tool in testing.

The other way is to define a (Antlr) module that the Geode modules depend
on.  The dependency could be explicitly added in IntelliJ to geode-core
module. The Antlr module could be built using the Gradle task defined in
the Geode Gradle build.  However, this would get stomped every time someone
re-imported the Gradle build files for Geode.

Probably the best option is as *Udo* described, or to first run a
clean/build with Gradle, then build/test in IntelliJ (assuming IDEA does
not blow away the build output on rebuilds).

Anyhow...


[1] https://projectlombok.org/


On Thu, Jan 5, 2017 at 1:46 PM, Udo Kohlmeyer  wrote:

> Maybe you tell IntelliJ to use gradle rather than its internal delegates.
>
>
> On 1/5/17 13:35, Dan Smith wrote:
>
> John - yes, there's a new gradle task. The task that needs run is
> geode-core:generateGrammarSource. For eclipse, we made the eclipse task
> depend on that task. If we can figure out how to get intellij to
> automatically run that task that sounds like the way to go.
>
> -Dan
>
> On Thu, Jan 5, 2017 at 12:47 PM, Udo Kohlmeyer  
> 
> wrote:
>
>
> In the newer IntelliJ you can actually have IntelliJ invoke the gradle
> commands for build/run/build instead of its own internal implementation.
>
> --Udo
>
>
>
> On 1/5/17 12:45, John Blum wrote:
>
>
> @Kirk - Is it part of a new (Gradle) build step to generate the Antlr
> classes from source?  In which case, you can configure IntelliJ to perform
> this step during compiling I believe.
>
> On Thu, Jan 5, 2017 at 12:39 PM, Kirk Lund  
>  wrote:
>
> Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why
>
> should a "./gradlew clean build" from command-line be required to get
> IntelliJ to work?
>
> -Kirk
>
>
> On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer  
> 
> wrote:
>
> I had the same problem. gradle clean build did the trick for me
>
>
>
> On 12/27/16 13:45, Bruce Schuchardt wrote:
>
> Actually neither refreshing from gradle nor creating a new Intellij
>
> project worked.  I had to go to the "other" tasks under geode-core in
>
>
> the
>
> Gradle window and set "generateGrammarSource" to run before building.
>
> Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :
>
> Refreshing your project from gradle ought to work to. Eclipse users
>
> will
>
> probably need to run ./gradlew eclipse and refresh their eclipse
>
> project.
>
> There is a new generated-src directory that needs to be on the source
>
> path.
>
> -Dan
>
> On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt 
> wrote:
>
> I did a pull today on my Windows 7 laptop and my IntelliJ build
> started
>
>
> failing with compilation errors looking for "OQLLexerTokenTypes".
>
>
> This
>
> comes from the fix for GEODE-165. Refreshing the IntelliJ build
>
> structure
> picked up the antlr tasks needed to generate this and other OQL
> source
> files but IntelliJ would not execute them.
>
> You either need to do a command-line build or close your IntelliJ
> project
> and import the gradle build into a new IntelliJ project.
>
>
>
>
>
>


-- 
-John
john.blum10101 (skype)

Re: User permissions for Galen O'Sullivan

[Galen M O'Sullivan]

Thanks, Mark! I suppose I'll add a brief introduction:

Hi, I'm Galen O'Sullivan. I joined Pivotal fairly recently. I've previously
worked at New Relic and Coherent Logix. In my free time I've been playing
with Rust and the Ergodox (though not at the same time). I think it's
pretty awesome that I can get paid to work on open source software.

Cheers!

Galen

On Thu, Jan 5, 2017 at 12:03 PM, Anthony Baker  wrote:

> Thanks Mark.  I updated [1] with this process note.
>
> Anthony
>
> [1] https://cwiki.apache.org/confluence/display/GEODE/Developer+Workflow
>
> > On Jan 5, 2017, at 11:39 AM, Mark Bretl  wrote:
> >
> > Hi Udo (and Galen),
> >
> > I have added Galen to the Geode project in JIRA.
> >
> > For future reference, we highly encourage new contributors to ask for
> > themselves as a way of introducing themselves to the community. I think
> we
> > should add this 'instruction' to the Community page on the site [1]
> >
> > --Mark
> >
> > [1] http://geode.apache.org/community/
> >
> > On Thu, Jan 5, 2017 at 11:19 AM, Udo Kohlmeyer 
> > wrote:
> >
> >> Hi there,
> >>
> >> Can someone with the relevant powers and permissions add Galen
> O'Sullivan
> >> as a contributor in Apache Jira?
> >>
> >> --Udo
> >>
> >>
>
>

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer]

+1


On 1/5/17 13:58, John Blum wrote:

In general, I think it would be useful to have a `start/stop/status
*service*` where services could be any one of [CacheServer,
GatewayReceiver, RedisService, MemcachedService, HttpService, etc].  As
user/developer, it would be useful to be able to control the embedded
services in one or more GemFire/Geode nodes in the cluster.

On Thu, Jan 5, 2017 at 1:57 PM, Udo Kohlmeyer  wrote:


+2



On 1/5/17 13:53, Kirk Lund wrote:


Ok #3 makes sense then. It's not that the Cache initialization is broken,
it's that some people want to hook in some custom initialization at the
end
of cache creation but before starting the ClientServer component.

I think it would make the most sense to have Cache initialization
callbacks
(this has been commonly requested by users for as long as I can remember).

It would also make sense to add lifecycle control commands for starting
and
stopping the ClientServer component (since this isn't a workaround for
some
sinister bug). If we design the start clientserver command correctly then
it's one more step towards completing cluster config in such a way that no
one needs cache.xml anymore. Right now if a user wants to create multiple
ClientServer endpoints then they have to use cache.xml in addition to
starting the default-server with the start server command.


On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer 
wrote:

Take this scenario as an example.

1) start server
2) Cache initializes and starts cacheserver
3) run custom code to build up meta structures for custom implementation

In this scenario, the cache has initialized and the cacheserver has been
started. So clients can start interacting with the server whilst it is
trying to build up custom add meta structures. Which may mean that the
client could receive incorrect results for queries or incorrect behavior
due to the data structures being "not ready"

If the capability is introduced to manually start the cacheserver then
this could go away.

1) start server
2) Cache initializes
3) run custom code to build up meta structures for custom implementation
4) start cacheserver

I agree, adding this flag because it did not correctly initialize the
cache/region/data structures that is crazy. If there is an issue where a
server has started up and is still waiting to GII messages, that should
be
addressed as a bug.

--Udo


On 1/5/17 12:55, Kirk Lund wrote:

So here's the what's going on: a User is starting Servers using "start

server" and apparently Clients are able to connect and perform
operations
*before* the Cache has completed initialization. So now, I'm being asked
to
change "start server" into a 2-command process (as an option):

1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1

I think this is crazy. If this is a problem then Geode Client/Server
has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.

The launcher class used by GFSH is ServerLauncher, not the older
deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is
connected
and Cache is created.

So I'm trying to understand why we're trying to solve this in GFSH
instead
of in the Server code.

-Kirk


On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:

How are you starting up your system? If you initialize a system with a


cache.xml or cluster configuration, the cache server and gateway
acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).

If you are using the API, it's up to you to start the cache server
last.
I
don't think there is any latch we can add in that case unless we also
added
a method to indicate that you are done configuring the system.

-Dan

On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
wrote:

To be honest I always just thought it was there. I bet most users do.
This

might explain some "unexplained" inconsistencies I have seen at a

customer.

--

Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:

So, I'm looking into an issue in which the Geode Server starts up and


accepts connections from Clients and starts handling their requests

before

its Cache has completed initialization.

Regions have a series of initialization latches that local puts and

gets

are forced to wait on. For example, initializationLatchAfterGetIni


tialImage
is released after GII completes for that Region. Local puts and gets

are

not allowed to be handled until after GII completes.


I would expect the Cache to have an initialization latch as well that
Client 

Re: Server accepts clients before its cache is initialized

[John Blum]

In general, I think it would be useful to have a `start/stop/status
*service*` where services could be any one of [CacheServer,
GatewayReceiver, RedisService, MemcachedService, HttpService, etc].  As
user/developer, it would be useful to be able to control the embedded
services in one or more GemFire/Geode nodes in the cluster.

On Thu, Jan 5, 2017 at 1:57 PM, Udo Kohlmeyer  wrote:

> +2
>
>
>
> On 1/5/17 13:53, Kirk Lund wrote:
>
>> Ok #3 makes sense then. It's not that the Cache initialization is broken,
>> it's that some people want to hook in some custom initialization at the
>> end
>> of cache creation but before starting the ClientServer component.
>>
>> I think it would make the most sense to have Cache initialization
>> callbacks
>> (this has been commonly requested by users for as long as I can remember).
>>
>> It would also make sense to add lifecycle control commands for starting
>> and
>> stopping the ClientServer component (since this isn't a workaround for
>> some
>> sinister bug). If we design the start clientserver command correctly then
>> it's one more step towards completing cluster config in such a way that no
>> one needs cache.xml anymore. Right now if a user wants to create multiple
>> ClientServer endpoints then they have to use cache.xml in addition to
>> starting the default-server with the start server command.
>>
>>
>> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer 
>> wrote:
>>
>> Take this scenario as an example.
>>>
>>> 1) start server
>>> 2) Cache initializes and starts cacheserver
>>> 3) run custom code to build up meta structures for custom implementation
>>>
>>> In this scenario, the cache has initialized and the cacheserver has been
>>> started. So clients can start interacting with the server whilst it is
>>> trying to build up custom add meta structures. Which may mean that the
>>> client could receive incorrect results for queries or incorrect behavior
>>> due to the data structures being "not ready"
>>>
>>> If the capability is introduced to manually start the cacheserver then
>>> this could go away.
>>>
>>> 1) start server
>>> 2) Cache initializes
>>> 3) run custom code to build up meta structures for custom implementation
>>> 4) start cacheserver
>>>
>>> I agree, adding this flag because it did not correctly initialize the
>>> cache/region/data structures that is crazy. If there is an issue where a
>>> server has started up and is still waiting to GII messages, that should
>>> be
>>> addressed as a bug.
>>>
>>> --Udo
>>>
>>>
>>> On 1/5/17 12:55, Kirk Lund wrote:
>>>
>>> So here's the what's going on: a User is starting Servers using "start
 server" and apparently Clients are able to connect and perform
 operations
 *before* the Cache has completed initialization. So now, I'm being asked
 to
 change "start server" into a 2-command process (as an option):

 1) gfsh> start server --name=Server1 --disable-default-server
 2) User waits until the Cache initialization is completed
 3) gfsh> start client-server-acceptor --name=Server1

 I think this is crazy. If this is a problem then Geode Client/Server
 has a
 bigger problem and this requires a fix in Cache initialization, NOT by
 adding a new GFSH command.

 The launcher class used by GFSH is ServerLauncher, not the older
 deprecated
 CacheServerLauncher. But what you're stating is still correct:
 ServerLauncher starts the Client/Server acceptor AFTER the DS is
 connected
 and Cache is created.

 So I'm trying to understand why we're trying to solve this in GFSH
 instead
 of in the Server code.

 -Kirk


 On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:

 How are you starting up your system? If you initialize a system with a

> cache.xml or cluster configuration, the cache server and gateway
> acceptors
> are started last (see CacheCreation.create). If your cache server is
> started using gfsh start server, I believe the acceptor part is also
> started last (see CacheServerLauncher.createCache).
>
> If you are using the API, it's up to you to start the cache server
> last.
> I
> don't think there is any latch we can add in that case unless we also
> added
> a method to indicate that you are done configuring the system.
>
> -Dan
>
> On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
> wrote:
>
> To be honest I always just thought it was there. I bet most users do.
> This
>
> might explain some "unexplained" inconsistencies I have seen at a
>>
>> customer.
>
> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: 631-835-4771
>>
>> On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:
>>
>> So, I'm looking into an issue in which the Geode Server 

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer]

+2


On 1/5/17 13:53, Kirk Lund wrote:

Ok #3 makes sense then. It's not that the Cache initialization is broken,
it's that some people want to hook in some custom initialization at the end
of cache creation but before starting the ClientServer component.

I think it would make the most sense to have Cache initialization callbacks
(this has been commonly requested by users for as long as I can remember).

It would also make sense to add lifecycle control commands for starting and
stopping the ClientServer component (since this isn't a workaround for some
sinister bug). If we design the start clientserver command correctly then
it's one more step towards completing cluster config in such a way that no
one needs cache.xml anymore. Right now if a user wants to create multiple
ClientServer endpoints then they have to use cache.xml in addition to
starting the default-server with the start server command.


On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer  wrote:


Take this scenario as an example.

1) start server
2) Cache initializes and starts cacheserver
3) run custom code to build up meta structures for custom implementation

In this scenario, the cache has initialized and the cacheserver has been
started. So clients can start interacting with the server whilst it is
trying to build up custom add meta structures. Which may mean that the
client could receive incorrect results for queries or incorrect behavior
due to the data structures being "not ready"

If the capability is introduced to manually start the cacheserver then
this could go away.

1) start server
2) Cache initializes
3) run custom code to build up meta structures for custom implementation
4) start cacheserver

I agree, adding this flag because it did not correctly initialize the
cache/region/data structures that is crazy. If there is an issue where a
server has started up and is still waiting to GII messages, that should be
addressed as a bug.

--Udo


On 1/5/17 12:55, Kirk Lund wrote:


So here's the what's going on: a User is starting Servers using "start
server" and apparently Clients are able to connect and perform operations
*before* the Cache has completed initialization. So now, I'm being asked
to
change "start server" into a 2-command process (as an option):

1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1

I think this is crazy. If this is a problem then Geode Client/Server has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.

The launcher class used by GFSH is ServerLauncher, not the older
deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
and Cache is created.

So I'm trying to understand why we're trying to solve this in GFSH instead
of in the Server code.

-Kirk


On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:

How are you starting up your system? If you initialize a system with a

cache.xml or cluster configuration, the cache server and gateway
acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).

If you are using the API, it's up to you to start the cache server last.
I
don't think there is any latch we can add in that case unless we also
added
a method to indicate that you are done configuring the system.

-Dan

On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
wrote:

To be honest I always just thought it was there. I bet most users do.
This


might explain some "unexplained" inconsistencies I have seen at a


customer.


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:

So, I'm looking into an issue in which the Geode Server starts up and

accepts connections from Clients and starts handling their requests


before


its Cache has completed initialization.

Regions have a series of initialization latches that local puts and


gets
are forced to wait on. For example, initializationLatchAfterGetIni

tialImage
is released after GII completes for that Region. Local puts and gets


are
not allowed to be handled until after GII completes.

I would expect the Cache to have an initialization latch as well that
Client requests have to wait on before the Geode Server completes Cache
initialization.

Does anyone know why Cache or AcceptorImpl don't have an initialization
latch like this? Does anyone have a good reason to not add such an
initialization latch to protect incoming Client requests?

Thanks,
Kirk

Re: Server accepts clients before its cache is initialized

[Kirk Lund]

Ok #3 makes sense then. It's not that the Cache initialization is broken,
it's that some people want to hook in some custom initialization at the end
of cache creation but before starting the ClientServer component.

I think it would make the most sense to have Cache initialization callbacks
(this has been commonly requested by users for as long as I can remember).

It would also make sense to add lifecycle control commands for starting and
stopping the ClientServer component (since this isn't a workaround for some
sinister bug). If we design the start clientserver command correctly then
it's one more step towards completing cluster config in such a way that no
one needs cache.xml anymore. Right now if a user wants to create multiple
ClientServer endpoints then they have to use cache.xml in addition to
starting the default-server with the start server command.


On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer  wrote:

> Take this scenario as an example.
>
> 1) start server
> 2) Cache initializes and starts cacheserver
> 3) run custom code to build up meta structures for custom implementation
>
> In this scenario, the cache has initialized and the cacheserver has been
> started. So clients can start interacting with the server whilst it is
> trying to build up custom add meta structures. Which may mean that the
> client could receive incorrect results for queries or incorrect behavior
> due to the data structures being "not ready"
>
> If the capability is introduced to manually start the cacheserver then
> this could go away.
>
> 1) start server
> 2) Cache initializes
> 3) run custom code to build up meta structures for custom implementation
> 4) start cacheserver
>
> I agree, adding this flag because it did not correctly initialize the
> cache/region/data structures that is crazy. If there is an issue where a
> server has started up and is still waiting to GII messages, that should be
> addressed as a bug.
>
> --Udo
>
>
> On 1/5/17 12:55, Kirk Lund wrote:
>
>> So here's the what's going on: a User is starting Servers using "start
>> server" and apparently Clients are able to connect and perform operations
>> *before* the Cache has completed initialization. So now, I'm being asked
>> to
>> change "start server" into a 2-command process (as an option):
>>
>> 1) gfsh> start server --name=Server1 --disable-default-server
>> 2) User waits until the Cache initialization is completed
>> 3) gfsh> start client-server-acceptor --name=Server1
>>
>> I think this is crazy. If this is a problem then Geode Client/Server has a
>> bigger problem and this requires a fix in Cache initialization, NOT by
>> adding a new GFSH command.
>>
>> The launcher class used by GFSH is ServerLauncher, not the older
>> deprecated
>> CacheServerLauncher. But what you're stating is still correct:
>> ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
>> and Cache is created.
>>
>> So I'm trying to understand why we're trying to solve this in GFSH instead
>> of in the Server code.
>>
>> -Kirk
>>
>>
>> On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:
>>
>> How are you starting up your system? If you initialize a system with a
>>> cache.xml or cluster configuration, the cache server and gateway
>>> acceptors
>>> are started last (see CacheCreation.create). If your cache server is
>>> started using gfsh start server, I believe the acceptor part is also
>>> started last (see CacheServerLauncher.createCache).
>>>
>>> If you are using the API, it's up to you to start the cache server last.
>>> I
>>> don't think there is any latch we can add in that case unless we also
>>> added
>>> a method to indicate that you are done configuring the system.
>>>
>>> -Dan
>>>
>>> On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
>>> wrote:
>>>
>>> To be honest I always just thought it was there. I bet most users do.

>>> This
>>>
 might explain some "unexplained" inconsistencies I have seen at a

>>> customer.
>>>
 --
 Mike Stolz
 Principal Engineer, GemFire Product Manager
 Mobile: 631-835-4771

 On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:

 So, I'm looking into an issue in which the Geode Server starts up and
> accepts connections from Clients and starts handling their requests
>
 before

> its Cache has completed initialization.
>
> Regions have a series of initialization latches that local puts and
>
 gets
>>>
 are forced to wait on. For example, initializationLatchAfterGetIni
> tialImage
> is released after GII completes for that Region. Local puts and gets
>
 are
>>>
 not allowed to be handled until after GII completes.
>
> I would expect the Cache to have an initialization latch as well that
> Client requests have to wait on before the Geode Server completes Cache
> initialization.
>
> Does anyone know why Cache or 

Re: Server accepts clients before its cache is initialized

[Bruce Schuchardt]

I think this is the kind of thing that's wanted, though it would be nice 
to be able to automate it, maybe through cache-server life cycle 
events.  In Geode the cache is always fully initialized prior to 
starting the cache server.


Le 1/5/2017 à 1:30 PM, Dan Smith a écrit :

Udo - could your use case be satisfied just by doing somthing like this?

1) gfsh start server --disable-default-server
2) Run your custom code
3) As the last part of your custom code, call Cache.addCacheServer

-Dan

On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer  wrote:


Take this scenario as an example.

1) start server
2) Cache initializes and starts cacheserver
3) run custom code to build up meta structures for custom implementation

In this scenario, the cache has initialized and the cacheserver has been
started. So clients can start interacting with the server whilst it is
trying to build up custom add meta structures. Which may mean that the
client could receive incorrect results for queries or incorrect behavior
due to the data structures being "not ready"

If the capability is introduced to manually start the cacheserver then
this could go away.

1) start server
2) Cache initializes
3) run custom code to build up meta structures for custom implementation
4) start cacheserver

I agree, adding this flag because it did not correctly initialize the
cache/region/data structures that is crazy. If there is an issue where a
server has started up and is still waiting to GII messages, that should be
addressed as a bug.

--Udo


On 1/5/17 12:55, Kirk Lund wrote:


So here's the what's going on: a User is starting Servers using "start
server" and apparently Clients are able to connect and perform operations
*before* the Cache has completed initialization. So now, I'm being asked
to
change "start server" into a 2-command process (as an option):

1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1

I think this is crazy. If this is a problem then Geode Client/Server has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.

The launcher class used by GFSH is ServerLauncher, not the older
deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
and Cache is created.

So I'm trying to understand why we're trying to solve this in GFSH instead
of in the Server code.

-Kirk


On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:

How are you starting up your system? If you initialize a system with a

cache.xml or cluster configuration, the cache server and gateway
acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).

If you are using the API, it's up to you to start the cache server last.
I
don't think there is any latch we can add in that case unless we also
added
a method to indicate that you are done configuring the system.

-Dan

On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
wrote:

To be honest I always just thought it was there. I bet most users do.
This


might explain some "unexplained" inconsistencies I have seen at a


customer.


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:

So, I'm looking into an issue in which the Geode Server starts up and

accepts connections from Clients and starts handling their requests


before


its Cache has completed initialization.

Regions have a series of initialization latches that local puts and


gets
are forced to wait on. For example, initializationLatchAfterGetIni

tialImage
is released after GII completes for that Region. Local puts and gets


are
not allowed to be handled until after GII completes.

I would expect the Cache to have an initialization latch as well that
Client requests have to wait on before the Geode Server completes Cache
initialization.

Does anyone know why Cache or AcceptorImpl don't have an initialization
latch like this? Does anyone have a good reason to not add such an
initialization latch to protect incoming Client requests?

Thanks,
Kirk

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Udo Kohlmeyer]

Maybe you tell IntelliJ to use gradle rather than its internal delegates.


On 1/5/17 13:35, Dan Smith wrote:

John - yes, there's a new gradle task. The task that needs run is
geode-core:generateGrammarSource. For eclipse, we made the eclipse task
depend on that task. If we can figure out how to get intellij to
automatically run that task that sounds like the way to go.

-Dan

On Thu, Jan 5, 2017 at 12:47 PM, Udo Kohlmeyer 
wrote:


In the newer IntelliJ you can actually have IntelliJ invoke the gradle
commands for build/run/build instead of its own internal implementation.

--Udo



On 1/5/17 12:45, John Blum wrote:


@Kirk - Is it part of a new (Gradle) build step to generate the Antlr
classes from source?  In which case, you can configure IntelliJ to perform
this step during compiling I believe.

On Thu, Jan 5, 2017 at 12:39 PM, Kirk Lund  wrote:

Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why

should a "./gradlew clean build" from command-line be required to get
IntelliJ to work?

-Kirk


On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer 
wrote:

I had the same problem. gradle clean build did the trick for me



On 12/27/16 13:45, Bruce Schuchardt wrote:

Actually neither refreshing from gradle nor creating a new Intellij

project worked.  I had to go to the "other" tasks under geode-core in


the
Gradle window and set "generateGrammarSource" to run before building.

Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :

Refreshing your project from gradle ought to work to. Eclipse users
will

probably need to run ./gradlew eclipse and refresh their eclipse

project.

There is a new generated-src directory that needs to be on the source

path.

-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt <
bschucha...@pivotal.io>
wrote:

I did a pull today on my Windows 7 laptop and my IntelliJ build
started


failing with compilation errors looking for "OQLLexerTokenTypes".


This

comes from the fix for GEODE-165. Refreshing the IntelliJ build

structure
picked up the antlr tasks needed to generate this and other OQL
source
files but IntelliJ would not execute them.

You either need to do a command-line build or close your IntelliJ
project
and import the gradle build into a new IntelliJ project.

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Dan Smith]

John - yes, there's a new gradle task. The task that needs run is
geode-core:generateGrammarSource. For eclipse, we made the eclipse task
depend on that task. If we can figure out how to get intellij to
automatically run that task that sounds like the way to go.

-Dan

On Thu, Jan 5, 2017 at 12:47 PM, Udo Kohlmeyer 
wrote:

> In the newer IntelliJ you can actually have IntelliJ invoke the gradle
> commands for build/run/build instead of its own internal implementation.
>
> --Udo
>
>
>
> On 1/5/17 12:45, John Blum wrote:
>
>> @Kirk - Is it part of a new (Gradle) build step to generate the Antlr
>> classes from source?  In which case, you can configure IntelliJ to perform
>> this step during compiling I believe.
>>
>> On Thu, Jan 5, 2017 at 12:39 PM, Kirk Lund  wrote:
>>
>> Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why
>>> should a "./gradlew clean build" from command-line be required to get
>>> IntelliJ to work?
>>>
>>> -Kirk
>>>
>>>
>>> On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer 
>>> wrote:
>>>
>>> I had the same problem. gradle clean build did the trick for me



 On 12/27/16 13:45, Bruce Schuchardt wrote:

 Actually neither refreshing from gradle nor creating a new Intellij
> project worked.  I had to go to the "other" tasks under geode-core in
>
 the
>>>
 Gradle window and set "generateGrammarSource" to run before building.
>
> Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :
>
> Refreshing your project from gradle ought to work to. Eclipse users
>>
> will
>>>
 probably need to run ./gradlew eclipse and refresh their eclipse
>>
> project.
>>>
 There is a new generated-src directory that needs to be on the source
>> path.
>>
>> -Dan
>>
>> On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt <
>> bschucha...@pivotal.io>
>> wrote:
>>
>> I did a pull today on my Windows 7 laptop and my IntelliJ build
>> started
>>
>>> failing with compilation errors looking for "OQLLexerTokenTypes".
>>>
>> This
>>>
 comes from the fix for GEODE-165. Refreshing the IntelliJ build
>>> structure
>>> picked up the antlr tasks needed to generate this and other OQL
>>> source
>>> files but IntelliJ would not execute them.
>>>
>>> You either need to do a command-line build or close your IntelliJ
>>> project
>>> and import the gradle build into a new IntelliJ project.
>>>
>>>
>>>
>>
>>
>

[jira] [Commented] (GEODE-2227) AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user vectorijk commented on the issue:

https://github.com/apache/geode/pull/330
  
@metatype I have addressed that.


> AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError 
> on Windows
> ---
>
> Key: GEODE-2227
> URL: https://issues.apache.org/jira/browse/GEODE-2227
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>Assignee: Kai Jiang
>  Labels: IntegrationTest, Windows
>
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.geode.pdx.AutoSerializableJUnitTest.testMultipleClassLoaders(AutoSerializableJUnitTest.java:1275)
>   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.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: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 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> 

[GitHub] geode issue #330: [GEODE-2227] AutoSerializableJUnitTest.testMultipleClassLo...

[vectorijk]

Github user vectorijk commented on the issue:

https://github.com/apache/geode/pull/330
  
@metatype I have addressed that.


---
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] [Created] (GEODE-2271) Reduce pdx type id generation for string fields in JSON

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2271:
--

 Summary: Reduce pdx type id generation for string fields in JSON
 Key: GEODE-2271
 URL: https://issues.apache.org/jira/browse/GEODE-2271
 Project: Geode
  Issue Type: Bug
  Components: serialization
Reporter: Hitesh Khamesra


JSONFormatter converts JSON to Pdx stream. While converting this any JSON field 
can have three values(fiefdValue, NULL, FieldNotexist). That can cause three 
pdxTypeIds in geode. To avoid this we need merge  (fiefdValue, NULL) in one 
pdxtype



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

[jira] [Assigned] (GEODE-2271) Reduce pdx type id generation for string fields in JSON

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra reassigned GEODE-2271:
--

Assignee: Hitesh Khamesra

> Reduce pdx type id generation for string fields in JSON
> ---
>
> Key: GEODE-2271
> URL: https://issues.apache.org/jira/browse/GEODE-2271
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
>
> JSONFormatter converts JSON to Pdx stream. While converting this any JSON 
> field can have three values(fiefdValue, NULL, FieldNotexist). That can cause 
> three pdxTypeIds in geode. To avoid this we need merge  (fiefdValue, NULL) in 
> one pdxtype



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

Re: Server accepts clients before its cache is initialized

[Dan Smith]

Udo - could your use case be satisfied just by doing somthing like this?

1) gfsh start server --disable-default-server
2) Run your custom code
3) As the last part of your custom code, call Cache.addCacheServer

-Dan

On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer  wrote:

> Take this scenario as an example.
>
> 1) start server
> 2) Cache initializes and starts cacheserver
> 3) run custom code to build up meta structures for custom implementation
>
> In this scenario, the cache has initialized and the cacheserver has been
> started. So clients can start interacting with the server whilst it is
> trying to build up custom add meta structures. Which may mean that the
> client could receive incorrect results for queries or incorrect behavior
> due to the data structures being "not ready"
>
> If the capability is introduced to manually start the cacheserver then
> this could go away.
>
> 1) start server
> 2) Cache initializes
> 3) run custom code to build up meta structures for custom implementation
> 4) start cacheserver
>
> I agree, adding this flag because it did not correctly initialize the
> cache/region/data structures that is crazy. If there is an issue where a
> server has started up and is still waiting to GII messages, that should be
> addressed as a bug.
>
> --Udo
>
>
> On 1/5/17 12:55, Kirk Lund wrote:
>
>> So here's the what's going on: a User is starting Servers using "start
>> server" and apparently Clients are able to connect and perform operations
>> *before* the Cache has completed initialization. So now, I'm being asked
>> to
>> change "start server" into a 2-command process (as an option):
>>
>> 1) gfsh> start server --name=Server1 --disable-default-server
>> 2) User waits until the Cache initialization is completed
>> 3) gfsh> start client-server-acceptor --name=Server1
>>
>> I think this is crazy. If this is a problem then Geode Client/Server has a
>> bigger problem and this requires a fix in Cache initialization, NOT by
>> adding a new GFSH command.
>>
>> The launcher class used by GFSH is ServerLauncher, not the older
>> deprecated
>> CacheServerLauncher. But what you're stating is still correct:
>> ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
>> and Cache is created.
>>
>> So I'm trying to understand why we're trying to solve this in GFSH instead
>> of in the Server code.
>>
>> -Kirk
>>
>>
>> On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:
>>
>> How are you starting up your system? If you initialize a system with a
>>> cache.xml or cluster configuration, the cache server and gateway
>>> acceptors
>>> are started last (see CacheCreation.create). If your cache server is
>>> started using gfsh start server, I believe the acceptor part is also
>>> started last (see CacheServerLauncher.createCache).
>>>
>>> If you are using the API, it's up to you to start the cache server last.
>>> I
>>> don't think there is any latch we can add in that case unless we also
>>> added
>>> a method to indicate that you are done configuring the system.
>>>
>>> -Dan
>>>
>>> On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz 
>>> wrote:
>>>
>>> To be honest I always just thought it was there. I bet most users do.

>>> This
>>>
 might explain some "unexplained" inconsistencies I have seen at a

>>> customer.
>>>
 --
 Mike Stolz
 Principal Engineer, GemFire Product Manager
 Mobile: 631-835-4771

 On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:

 So, I'm looking into an issue in which the Geode Server starts up and
> accepts connections from Clients and starts handling their requests
>
 before

> its Cache has completed initialization.
>
> Regions have a series of initialization latches that local puts and
>
 gets
>>>
 are forced to wait on. For example, initializationLatchAfterGetIni
> tialImage
> is released after GII completes for that Region. Local puts and gets
>
 are
>>>
 not allowed to be handled until after GII completes.
>
> I would expect the Cache to have an initialization latch as well that
> Client requests have to wait on before the Geode Server completes Cache
> initialization.
>
> Does anyone know why Cache or AcceptorImpl don't have an initialization
> latch like this? Does anyone have a good reason to not add such an
> initialization latch to protect incoming Client requests?
>
> Thanks,
> Kirk
>
>
>

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer]

Take this scenario as an example.

1) start server
2) Cache initializes and starts cacheserver
3) run custom code to build up meta structures for custom implementation

In this scenario, the cache has initialized and the cacheserver has been 
started. So clients can start interacting with the server whilst it is 
trying to build up custom add meta structures. Which may mean that the 
client could receive incorrect results for queries or incorrect behavior 
due to the data structures being "not ready"


If the capability is introduced to manually start the cacheserver then 
this could go away.


1) start server
2) Cache initializes
3) run custom code to build up meta structures for custom implementation
4) start cacheserver

I agree, adding this flag because it did not correctly initialize the 
cache/region/data structures that is crazy. If there is an issue where a 
server has started up and is still waiting to GII messages, that should 
be addressed as a bug.


--Udo

On 1/5/17 12:55, Kirk Lund wrote:

So here's the what's going on: a User is starting Servers using "start
server" and apparently Clients are able to connect and perform operations
*before* the Cache has completed initialization. So now, I'm being asked to
change "start server" into a 2-command process (as an option):

1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1

I think this is crazy. If this is a problem then Geode Client/Server has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.

The launcher class used by GFSH is ServerLauncher, not the older deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
and Cache is created.

So I'm trying to understand why we're trying to solve this in GFSH instead
of in the Server code.

-Kirk


On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:


How are you starting up your system? If you initialize a system with a
cache.xml or cluster configuration, the cache server and gateway acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).

If you are using the API, it's up to you to start the cache server last. I
don't think there is any latch we can add in that case unless we also added
a method to indicate that you are done configuring the system.

-Dan

On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz  wrote:


To be honest I always just thought it was there. I bet most users do.

This

might explain some "unexplained" inconsistencies I have seen at a

customer.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:


So, I'm looking into an issue in which the Geode Server starts up and
accepts connections from Clients and starts handling their requests

before

its Cache has completed initialization.

Regions have a series of initialization latches that local puts and

gets

are forced to wait on. For example, initializationLatchAfterGetIni
tialImage
is released after GII completes for that Region. Local puts and gets

are

not allowed to be handled until after GII completes.

I would expect the Cache to have an initialization latch as well that
Client requests have to wait on before the Geode Server completes Cache
initialization.

Does anyone know why Cache or AcceptorImpl don't have an initialization
latch like this? Does anyone have a good reason to not add such an
initialization latch to protect incoming Client requests?

Thanks,
Kirk

Re: Server accepts clients before its cache is initialized

[Kirk Lund]

So here's the what's going on: a User is starting Servers using "start
server" and apparently Clients are able to connect and perform operations
*before* the Cache has completed initialization. So now, I'm being asked to
change "start server" into a 2-command process (as an option):

1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1

I think this is crazy. If this is a problem then Geode Client/Server has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.

The launcher class used by GFSH is ServerLauncher, not the older deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
and Cache is created.

So I'm trying to understand why we're trying to solve this in GFSH instead
of in the Server code.

-Kirk


On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith  wrote:

> How are you starting up your system? If you initialize a system with a
> cache.xml or cluster configuration, the cache server and gateway acceptors
> are started last (see CacheCreation.create). If your cache server is
> started using gfsh start server, I believe the acceptor part is also
> started last (see CacheServerLauncher.createCache).
>
> If you are using the API, it's up to you to start the cache server last. I
> don't think there is any latch we can add in that case unless we also added
> a method to indicate that you are done configuring the system.
>
> -Dan
>
> On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz  wrote:
>
> > To be honest I always just thought it was there. I bet most users do.
> This
> > might explain some "unexplained" inconsistencies I have seen at a
> customer.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
> >
> > On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:
> >
> > > So, I'm looking into an issue in which the Geode Server starts up and
> > > accepts connections from Clients and starts handling their requests
> > before
> > > its Cache has completed initialization.
> > >
> > > Regions have a series of initialization latches that local puts and
> gets
> > > are forced to wait on. For example, initializationLatchAfterGetIni
> > > tialImage
> > > is released after GII completes for that Region. Local puts and gets
> are
> > > not allowed to be handled until after GII completes.
> > >
> > > I would expect the Cache to have an initialization latch as well that
> > > Client requests have to wait on before the Geode Server completes Cache
> > > initialization.
> > >
> > > Does anyone know why Cache or AcceptorImpl don't have an initialization
> > > latch like this? Does anyone have a good reason to not add such an
> > > initialization latch to protect incoming Client requests?
> > >
> > > Thanks,
> > > Kirk
> > >
> >
>

Re: OQLLexerTokenTypes - java: connot find symbol

[Kai Jiang]

I agreed with Jason. This happened in my environment several times. Clean
build could work.

Best,
Kai

On Thu, Jan 5, 2017 at 12:39 PM, Jason Huynh  wrote:

> I think a clean build and refreshing the intelij project should work.  I
> think the change removed those files and requires them to be generated from
> the build
>
> On Thu, Jan 5, 2017 at 12:36 PM Kirk Lund  wrote:
>
> > I rebased one of my feature branches on origin/develop, then refreshed
> > gradle in IntelliJ and then rebuilt my IntelliJ project but IntelliJ
> > insists that OQLLexerTokenTypes does not exist. My project is full of
> > errors like this:
> >
> > Error:(29, 51) java: cannot find symbol
> >   symbol:   class OQLLexerTokenTypes
> >   location: package org.apache.geode.cache.query.internal.parse
> >
> > Any ideas how to get my IntelliJ project working again without losing too
> > much time?
> >
> > Thanks,
> > Kirk
> >
>

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[John Blum]

@Kirk - Is it part of a new (Gradle) build step to generate the Antlr
classes from source?  In which case, you can configure IntelliJ to perform
this step during compiling I believe.

On Thu, Jan 5, 2017 at 12:39 PM, Kirk Lund  wrote:

> Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why
> should a "./gradlew clean build" from command-line be required to get
> IntelliJ to work?
>
> -Kirk
>
>
> On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer 
> wrote:
>
> > I had the same problem. gradle clean build did the trick for me
> >
> >
> >
> > On 12/27/16 13:45, Bruce Schuchardt wrote:
> >
> >> Actually neither refreshing from gradle nor creating a new Intellij
> >> project worked.  I had to go to the "other" tasks under geode-core in
> the
> >> Gradle window and set "generateGrammarSource" to run before building.
> >>
> >> Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :
> >>
> >>> Refreshing your project from gradle ought to work to. Eclipse users
> will
> >>> probably need to run ./gradlew eclipse and refresh their eclipse
> project.
> >>> There is a new generated-src directory that needs to be on the source
> >>> path.
> >>>
> >>> -Dan
> >>>
> >>> On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt <
> >>> bschucha...@pivotal.io>
> >>> wrote:
> >>>
> >>> I did a pull today on my Windows 7 laptop and my IntelliJ build started
>  failing with compilation errors looking for "OQLLexerTokenTypes".
> This
>  comes from the fix for GEODE-165. Refreshing the IntelliJ build
>  structure
>  picked up the antlr tasks needed to generate this and other OQL source
>  files but IntelliJ would not execute them.
> 
>  You either need to do a command-line build or close your IntelliJ
>  project
>  and import the gradle build into a new IntelliJ project.
> 
> 
> >>
> >
>



-- 
-John
john.blum10101 (skype)

Re: Server accepts clients before its cache is initialized

[Dan Smith]

How are you starting up your system? If you initialize a system with a
cache.xml or cluster configuration, the cache server and gateway acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).

If you are using the API, it's up to you to start the cache server last. I
don't think there is any latch we can add in that case unless we also added
a method to indicate that you are done configuring the system.

-Dan

On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz  wrote:

> To be honest I always just thought it was there. I bet most users do. This
> might explain some "unexplained" inconsistencies I have seen at a customer.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund  wrote:
>
> > So, I'm looking into an issue in which the Geode Server starts up and
> > accepts connections from Clients and starts handling their requests
> before
> > its Cache has completed initialization.
> >
> > Regions have a series of initialization latches that local puts and gets
> > are forced to wait on. For example, initializationLatchAfterGetIni
> > tialImage
> > is released after GII completes for that Region. Local puts and gets are
> > not allowed to be handled until after GII completes.
> >
> > I would expect the Cache to have an initialization latch as well that
> > Client requests have to wait on before the Geode Server completes Cache
> > initialization.
> >
> > Does anyone know why Cache or AcceptorImpl don't have an initialization
> > latch like this? Does anyone have a good reason to not add such an
> > initialization latch to protect incoming Client requests?
> >
> > Thanks,
> > Kirk
> >
>

Re: IntelliJ builds broken looking for OQLLexerTokenTypes.java

[Udo Kohlmeyer]

I believe that IntelliJ's gradle implementation will inspect the gradle 
files but it does not execute any task if not invoked.


So, I assume I've you were to run the build task in IntelliJ it could 
resolve this...



On 1/5/17 12:39, Kirk Lund wrote:

Refreshing IntelliJ from Gradle does NOT fix this for me. Question: why
should a "./gradlew clean build" from command-line be required to get
IntelliJ to work?

-Kirk


On Tue, Dec 27, 2016 at 1:47 PM, Udo Kohlmeyer 
wrote:


I had the same problem. gradle clean build did the trick for me



On 12/27/16 13:45, Bruce Schuchardt wrote:


Actually neither refreshing from gradle nor creating a new Intellij
project worked.  I had to go to the "other" tasks under geode-core in the
Gradle window and set "generateGrammarSource" to run before building.

Le 12/27/2016 à 11:54 AM, Dan Smith a écrit :


Refreshing your project from gradle ought to work to. Eclipse users will
probably need to run ./gradlew eclipse and refresh their eclipse project.
There is a new generated-src directory that needs to be on the source
path.

-Dan

On Tue, Dec 27, 2016 at 11:28 AM, Bruce Schuchardt <
bschucha...@pivotal.io>
wrote:

I did a pull today on my Windows 7 laptop and my IntelliJ build started

failing with compilation errors looking for "OQLLexerTokenTypes".  This
comes from the fix for GEODE-165. Refreshing the IntelliJ build
structure
picked up the antlr tasks needed to generate this and other OQL source
files but IntelliJ would not execute them.

You either need to do a command-line build or close your IntelliJ
project
and import the gradle build into a new IntelliJ project.

Re: OQLLexerTokenTypes - java: connot find symbol

[Jason Huynh]

I think a clean build and refreshing the intelij project should work.  I
think the change removed those files and requires them to be generated from
the build

On Thu, Jan 5, 2017 at 12:36 PM Kirk Lund  wrote:

> I rebased one of my feature branches on origin/develop, then refreshed
> gradle in IntelliJ and then rebuilt my IntelliJ project but IntelliJ
> insists that OQLLexerTokenTypes does not exist. My project is full of
> errors like this:
>
> Error:(29, 51) java: cannot find symbol
>   symbol:   class OQLLexerTokenTypes
>   location: package org.apache.geode.cache.query.internal.parse
>
> Any ideas how to get my IntelliJ project working again without losing too
> much time?
>
> Thanks,
> Kirk
>

[jira] [Commented] (GEODE-2016) Dependency configuration for javax.security.auth.message-api incorrect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2016:


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

GEODE-2016: change compile dependency to testCompile


> Dependency configuration for javax.security.auth.message-api incorrect
> --
>
> Key: GEODE-2016
> URL: https://issues.apache.org/jira/browse/GEODE-2016
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Swapnil Bawaskar
>Assignee: Anthony Baker
> Fix For: 1.1.0
>
>
> The dependency {{javax.security.auth.message-api-1.1}} pulled in by 
> extensions is declared to be a compile dependency, but it is only used in 
> tests, so it should be made a {{testCompile}} dependency.
> The definition is here: 
> https://github.com/apache/incubator-geode/blob/8a6a46abde1a7f08fcf4605877f60ce9480fb296/extensions/geode-modules-tomcat8/build.gradle#L39



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

[jira] [Resolved] (GEODE-1657) Source files should not contain Windows linefeeds

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1657.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> Source files should not contain Windows linefeeds
> -
>
> Key: GEODE-1657
> URL: https://issues.apache.org/jira/browse/GEODE-1657
> Project: Geode
>  Issue Type: Bug
>  Components: general
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Minor
> Fix For: 1.1.0
>
>
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/Server.java 
> contains ^M (Windows linefeeds).



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

[jira] [Commented] (GEODE-1657) Source files should not contain Windows linefeeds

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1657:


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

GEODE-1657 Remove silly ^M characters


> Source files should not contain Windows linefeeds
> -
>
> Key: GEODE-1657
> URL: https://issues.apache.org/jira/browse/GEODE-1657
> Project: Geode
>  Issue Type: Bug
>  Components: general
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Minor
> Fix For: 1.1.0
>
>
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/Server.java 
> contains ^M (Windows linefeeds).



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

Re: Review Request 55108: GEODE-2016: change compile dependency to testCompile

[Jason Huynh]

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


Ship it!




Ship It!

- Jason Huynh


On Dec. 31, 2016, 12:39 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55108/
> ---
> 
> (Updated Dec. 31, 2016, 12:39 a.m.)
> 
> 
> Review request for geode, Jason Huynh and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2016: change compile dependency to testCompile
> 
> 
> Diffs
> -
> 
>   extensions/geode-modules-tomcat8/build.gradle 
> df36ab320c2ceb1139b4ac10efcecf1b29b2931d 
> 
> Diff: https://reviews.apache.org/r/55108/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

[jira] [Resolved] (GEODE-1979) CI Failure: SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators

[Kirk Lund (JIRA)]

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

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

> CI Failure: 
> SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators
> -
>
> Key: GEODE-1979
> URL: https://issues.apache.org/jira/browse/GEODE-1979
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, management
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4157
> Revision: 8929e93bd129b303aae8f9e1b13daf3c3991d1a4
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 3 running on Host 
> cc1-co.gemstone.com with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators(SharedConfigurationUsingDirDUnitTest.java:108)
>   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.TestWatcher$1.evaluate(TestWatcher.java:55)
>   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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor300.invoke(Unknown Source)
>   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.GeneratedMethodAccessor299.invoke(Unknown Source)
>   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 
> 

[jira] [Closed] (GEODE-1989) CI failure: SharedConfigurationUsingDirDUnitTest updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1989.


> CI failure: SharedConfigurationUsingDirDUnitTest 
> updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart
> -
>
> Key: GEODE-1989
> URL: https://issues.apache.org/jira/browse/GEODE-1989
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Darrel Schneider
>Assignee: Kirk Lund
>  Labels: ci, flaky
>
> :geode-core:distributedTest
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest
>  > updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 2 running on Host 
> a9e7f8bc8ba0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:208)
> Caused by:
> com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
> lambda expression in 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest
>  was not fulfilled within 15 seconds.
> at 
> com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
> at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.lambda$updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart$bb17a952$2(SharedConfigurationUsingDirDUnitTest.java:209)
> 7578 tests completed, 1 failed, 588 skipped



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

[jira] [Resolved] (GEODE-1989) CI failure: SharedConfigurationUsingDirDUnitTest updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart

[Kirk Lund (JIRA)]

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

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

> CI failure: SharedConfigurationUsingDirDUnitTest 
> updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart
> -
>
> Key: GEODE-1989
> URL: https://issues.apache.org/jira/browse/GEODE-1989
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Darrel Schneider
>Assignee: Kirk Lund
>  Labels: ci, flaky
>
> :geode-core:distributedTest
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest
>  > updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 2 running on Host 
> a9e7f8bc8ba0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:208)
> Caused by:
> com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
> lambda expression in 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest
>  was not fulfilled within 15 seconds.
> at 
> com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
> at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.lambda$updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart$bb17a952$2(SharedConfigurationUsingDirDUnitTest.java:209)
> 7578 tests completed, 1 failed, 588 skipped



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

[jira] [Closed] (GEODE-1979) CI Failure: SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1979.


> CI Failure: 
> SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators
> -
>
> Key: GEODE-1979
> URL: https://issues.apache.org/jira/browse/GEODE-1979
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, management
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests
> Private Build #4157
> Revision: 8929e93bd129b303aae8f9e1b13daf3c3991d1a4
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 3 running on Host 
> cc1-co.gemstone.com with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.basicClusterConfigDirWithTwoLocators(SharedConfigurationUsingDirDUnitTest.java:108)
>   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.TestWatcher$1.evaluate(TestWatcher.java:55)
>   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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   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.GeneratedMethodAccessor300.invoke(Unknown Source)
>   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.GeneratedMethodAccessor299.invoke(Unknown Source)
>   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 
> 

[jira] [Updated] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1165:
-
Component/s: tests
 management
 gfsh

> CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky
> 
>
> Key: GEODE-1165
> URL: https://issues.apache.org/jira/browse/GEODE-1165
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, management, tests
>Affects Versions: 1.0.0-incubating
>Reporter: Jianxia Chen
>  Labels: CI, Flaky
>
> Several tests in SharedConfigurationUsingDirDUnitTest are flaky and fail 
> intermittently. One known cause is GEODE-2238 (one cause has been fixed and 
> committed). The timeout used by these tests is 15 seconds which is quite low 
> if a GC pause occurs.
> 1) GEODE-1165 includes BindException:
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
> cc2-ub.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
>   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.TestWatcher$1.evaluate(TestWatcher.java:55)
>   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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at 

[jira] [Updated] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[Kirk Lund (JIRA)]

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

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

> CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky
> 
>
> Key: GEODE-1165
> URL: https://issues.apache.org/jira/browse/GEODE-1165
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, management, tests
>Affects Versions: 1.0.0-incubating
>Reporter: Jianxia Chen
>Assignee: Kirk Lund
>  Labels: CI, Flaky
>
> Several tests in SharedConfigurationUsingDirDUnitTest are flaky and fail 
> intermittently. One known cause is GEODE-2238 (one cause has been fixed and 
> committed). The timeout used by these tests is 15 seconds which is quite low 
> if a GC pause occurs.
> 1) GEODE-1165 includes BindException:
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
> cc2-ub.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
>   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.TestWatcher$1.evaluate(TestWatcher.java:55)
>   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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at 

[jira] [Updated] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1165:
-
Description: 
Several tests in SharedConfigurationUsingDirDUnitTest are flaky and fail 
intermittently. One known cause is GEODE-2238 (one cause has been fixed and 
committed). The timeout used by these tests is 15 seconds which is quite low if 
a GC pause occurs.

1) GEODE-1165 includes BindException:
{noformat}
com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
cc2-ub.gemstone.com with 4 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
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.TestWatcher$1.evaluate(TestWatcher.java:55)
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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.messaging.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:106)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at 

[jira] [Updated] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1165:
-
Description: 
Several tests in SharedConfigurationUsingDirDUnitTest are flaky and fail 
intermittently. One known cause is GEODE-2238 (one cause has been fixed and 
committed). The timeout used by these tests is 15 seconds which is quite low if 
a GC pause occurs.

1) GEODE-1165 includes BindException
{noformat}
com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
cc2-ub.gemstone.com with 4 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
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.TestWatcher$1.evaluate(TestWatcher.java:55)
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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.messaging.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:106)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at 

[jira] [Updated] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1165:
-
Description: 
Several tests in 

com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
cc2-ub.gemstone.com with 4 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
at 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
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.TestWatcher$1.evaluate(TestWatcher.java:55)
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.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.messaging.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:106)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 

Re: Apache deadline for GEODE-2142 "Remove JSON.org dependency"

[Anthony Baker]

> On Jan 5, 2017, at 11:41 AM, Kirk Lund  wrote:
> 
> GEODE-2142 "Remove JSON.org dependency"
> 
> https://issues.apache.org/jira/browse/GEODE-2142
> 
> The deadline for all Apache projects to remove json.org is *April 30th 2017*.
> Right now the component is "build" for GEODE-2142.
> 
> There are 2 copies of json.org in Geode source code:
> 
> 1) geode-json/src/main/java/org/json/*
> 
> 2) geode-pulse/src/main/java/org/json/*
> 
> -Kirk

The pulse dependency could be removed fairly easily—it’s only used in 3 test 
classes.

Anthony

Re: Off-Heap Annotations

[Darrel Schneider]

It is just flags / configuration. The APIs would just let you set the
flags/configuration. You could also use APIs to read the offheap statistics.
Basically just allocate the offheap memory using "off-heap-memory-size" and
then configure one or more regions with offheap set to true. Any value
stored in that region will be stored in offheap memory instead of heap.


On Wed, Jan 4, 2017 at 11:29 PM, Dor Ben Dov  wrote:

> Kirk & Darrel & Hitesh,
>
> Thank you all for the detailed info on the off heap option.
>
> One more question, do I have any kind of API or it is purely flags /
> configuration?
>
> Regards,
> Dor
>
> -Original Message-
> From: Kirk Lund [mailto:kl...@apache.org]
> Sent: יום ג 03 ינואר 2017 22:47
> To: geode 
> Subject: Re: Off-Heap Annotations
>
> Oh yeah! We were hoping to get more feedback from users to find out what
> they want or need for migrating a region from heap to off-heap. Right now
> it doesn't support anything like that but it was definitely discussed.
>
>
> On Tue, Jan 3, 2017 at 12:27 PM, Hitesh Khamesra <
> hitesh...@yahoo.com.invalid> wrote:
>
> > I was considering the case when one want to change its "value" through
> > rolling upgrade. In an ideal world, I would expect that every node
> > will have the same heap/off configuration, but other can happen.
> >
> >
> >
> >   From: Kirk Lund 
> >  To: geode 
> >  Sent: Tuesday, January 3, 2017 12:16 PM
> >  Subject: Re: Off-Heap Annotations
> >
> > The region is required to be off-heap in every member in the cluster.
> > Imagine memberA with 12 GB heap, 100 GB off-heap and memberB with 8 GB
> > heap, 0 GB off-heap. What's the point of having replicated regionA be
> > off-heap in memberA but on heap in memberB? The region will always be
> > limited by the heap size of memberB. More importantly, the
> > ResourceManager would not handle things correctly unless regionA is
> > consistently off-heap in every member. The documentation also
> > recommends that every member have the same off-heap-memory-size
> > because of the way the ResourceManager is implemented as well. Any
> > major differences in memory size between members is a good way to
> > cause one or more of them to run out of memory unless you constrain the
> amount of data that can go into the region in some way.
> >
> >
> > On Tue, Jan 3, 2017 at 11:51 AM, Hitesh Khamesra <
> > hitesh...@yahoo.com.invalid> wrote:
> >
> > > >>>The first cluster member to create the region
> > > wins and all the other members need to conform to the first one's
> > > configuration.
> > > Is there any technical reason to check this? Or we just want same
> > > configuration across cluster.
> > >
> > >  From: Darrel Schneider 
> > >  To: dev@geode.apache.org
> > >  Sent: Tuesday, January 3, 2017 11:33 AM
> > >  Subject: Re: Off-Heap Annotations
> > >
> > > When a region is created you need to mark it as off-heap or on-heap.
> > > Once it is created you can not change it on that region.
> > > You can create and destroy regions on the fly.
> > >
> > > c
> > >
> > > On Tue, Jan 3, 2017 at 8:01 AM, Dor Ben Dov 
> > > wrote:
> > >
> > > > Udo,
> > > >
> > > > This means it can't be changed on the fly in runtime ? Need to be
> > flagged
> > > > before?
> > > >
> > > > Dor
> > > >
> > > > -Original Message-
> > > > From: Udo Kohlmeyer [mailto:u...@apache.org]
> > > > Sent: יום ג 03 ינואר 2017 17:32
> > > > To: dev@geode.apache.org
> > > > Subject: Re: Off-Heap Annotations
> > > >
> > > > Hi there Gal,
> > > >
> > > > That is not possible. A region is either on-heap or off-heap.
> > > >
> > > > --Udo
> > > >
> > > >
> > > > On 1/2/17 13:50, Gal Palmery wrote:
> > > > > Ok,
> > > > > So if I want to have just a certain part of the region off heap
> > > > > and
> > the
> > > > rest of it on heap - how do I do that?
> > > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Dan Smith [mailto:dsm...@pivotal.io]
> > > > > Sent: Monday, January 02, 2017 19:46
> > > > > To: dev@geode.apache.org
> > > > > Subject: Re: Off-Heap Annotations
> > > > >
> > > > > Hi Gal,
> > > > >
> > > > > The way to control what is on or off heap is when you configure
> > > > > a
> > > region.
> > > > > Regions that are configured with off-heap=true will store all of
> > > > > the
> > > > values in off heap memory, regions with off-heap= false will store
> > > > the values on the heap.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery
> > > > > 
> > > > wrote:
> > > > >
> > > > >> Thanks Kirk.
> > > > >>
> > > > >> for example, before I call put, I'd like to indicate to geode
> > > > >> server that I want to keep specific data off heap. how can I do
> that?
> > > > >> is there an api that will move data off or on heap?
> > > > >>
> > > > >> Gal
> > > > >>
> > > > >> -Original 

Apache deadline for GEODE-2142 "Remove JSON.org dependency"

[Kirk Lund]

GEODE-2142 "Remove JSON.org dependency"

https://issues.apache.org/jira/browse/GEODE-2142

The deadline for all Apache projects to remove json.org is *April 30th 2017*.
Right now the component is "build" for GEODE-2142.

There are 2 copies of json.org in Geode source code:

1) geode-json/src/main/java/org/json/*

2) geode-pulse/src/main/java/org/json/*

-Kirk

Re: User permissions for Galen O'Sullivan

[Mark Bretl]

Hi Udo (and Galen),

I have added Galen to the Geode project in JIRA.

For future reference, we highly encourage new contributors to ask for
themselves as a way of introducing themselves to the community. I think we
should add this 'instruction' to the Community page on the site [1]

--Mark

[1] http://geode.apache.org/community/

On Thu, Jan 5, 2017 at 11:19 AM, Udo Kohlmeyer 
wrote:

> Hi there,
>
> Can someone with the relevant powers and permissions add Galen O'Sullivan
> as a contributor in Apache Jira?
>
> --Udo
>
>

[jira] [Updated] (GEODE-2142) Remove JSON.org dependency

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2142:
-
Component/s: (was: management)

> Remove JSON.org dependency
> --
>
> Key: GEODE-2142
> URL: https://issues.apache.org/jira/browse/GEODE-2142
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Priority: Blocker
>
> ASF has determined that the JSON library should be treated as Category X and 
> is incompatible with ASLv2.
> We have until Apr-30, 2017 to remove this dependency.  Any release we ship 
> prior to that time must state this usage via NOTICE.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201611.mbox/%3ccajwfca2ox62mugp+-+-v6ktbkhhgkixucjcr9syes-azfp+...@mail.gmail.com%3e
> There are related reasons for removing the JSON library anyway, but this bug 
> captures the legal reasons.



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

[jira] [Updated] (GEODE-2142) Remove JSON.org dependency

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2142:
-
Component/s: management

> Remove JSON.org dependency
> --
>
> Key: GEODE-2142
> URL: https://issues.apache.org/jira/browse/GEODE-2142
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Priority: Blocker
>
> ASF has determined that the JSON library should be treated as Category X and 
> is incompatible with ASLv2.
> We have until Apr-30, 2017 to remove this dependency.  Any release we ship 
> prior to that time must state this usage via NOTICE.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201611.mbox/%3ccajwfca2ox62mugp+-+-v6ktbkhhgkixucjcr9syes-azfp+...@mail.gmail.com%3e
> There are related reasons for removing the JSON library anyway, but this bug 
> captures the legal reasons.



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

User permissions for Galen O'Sullivan

[Udo Kohlmeyer]

Hi there,

Can someone with the relevant powers and permissions add Galen 
O'Sullivan as a contributor in Apache Jira?


--Udo

Server accepts clients before its cache is initialized

[Kirk Lund]

So, I'm looking into an issue in which the Geode Server starts up and
accepts connections from Clients and starts handling their requests before
its Cache has completed initialization.

Regions have a series of initialization latches that local puts and gets
are forced to wait on. For example, initializationLatchAfterGetInitialImage
is released after GII completes for that Region. Local puts and gets are
not allowed to be handled until after GII completes.

I would expect the Cache to have an initialization latch as well that
Client requests have to wait on before the Geode Server completes Cache
initialization.

Does anyone know why Cache or AcceptorImpl don't have an initialization
latch like this? Does anyone have a good reason to not add such an
initialization latch to protect incoming Client requests?

Thanks,
Kirk

[jira] [Updated] (GEODE-2269) It seems the gfsh "remove" command cannot remove r...

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller updated GEODE-2269:
---
Component/s: docs

> It seems the gfsh "remove" command cannot remove r...
> -
>
> Key: GEODE-2269
> URL: https://issues.apache.org/jira/browse/GEODE-2269
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Gregory Green
>
> It seems the gfsh "remove" command cannot remove region entries with a 0 
> length string key.
> gfsh>query --query="select toString().length() from /Recipient.keySet()"
> Result : true
> startCount : 0
> endCount   : 20
> Rows   : 3
> Result
> --
> 0
> 2
> 5
> gfsh>remove --region=/Recipient --key=""
> Message : Key is either empty or Null
> Result  : false
> gfsh>remove --region=/Recipient --key="''"
> Message : Key is either empty or Null
> Result  : false



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

Re: New proposal for type definitons

[Jacob Barrett]

If we are simply looking at ways to avoid the PDX type bloat then some
quick wins would be:
Presort JSON field names or remove the ordering dependency in PDX type
matching. I looked into removing or working around the ordering a while ago
when dealing with GPDB integration.
Stop this silliness of trying to conserver space by putting small numbers
in to smaller int fields and force all JSON numbers to be serialized as
BigDecimal. JSON does not define any other type of number so why are we
trying to?
Don't parse time in JSON. There is no standard or type for time in JSON.

This won't solve all bloat like that resulting for added or removed fields
but having a superset of those fields defined in the PDX metadata will only
cause memory bloat in storage. If your PDX type defines 100 fields but your
pdx instance only populates 1 the serialized form still records the null
values for the other 99 fields. If your 1 field happens to be the last
field then your performance goes to crap too since a getValue call has to
walk the entire structure from the first variable length field to find the
field you are looking for in the stream. You are way better off with more
types that define these smaller subsets of the document then one superset.
Optimizations should be made in the lookup in the PDX registry.

-Jake


On Wed, Jan 4, 2017 at 12:12 PM Udo Kohlmeyer  wrote:

> I like the idea of the self-describing and that if you are willing to
> take the memory hit, then storing the type definition as part of the
> data entry works. Although it WILL cause huge headaches:
>
>   * significant increase in memory
>   * performance degradation not only in the processing of the entry but
> every network hop it would incur
>
> My proposal, even if incredibly veiled under the JSON banner, was a type
> catalogue that would replace the current PDXTypeRegistry and that could
> form that basis of a greater data type service. One that does not only
> help with the serialization but also in converting from one type to
> another (JSON->Pdx) and formatting (import/export)  of decimal and date
> fields. I even had the idea that it could store things like secure
> fields (masking and obscuring of non-authorized access). But I see that
> this falls squarely in the realm of security and should not be put in
> the catalogue.
>
> I believe that we could live in the "best-of-both-worlds" were you could
> define (or have it automatically define) a type definition. Then the
> current logic would continue working as is. IF one then decides that it
> is too much effort or the structure cannot be concretely defined or one
> just does not care, then the "self-describing" entry type can be used.
> With the added memory footprint,etc...
>
> Serialization has always been something that, was supposed to the
> pluggable. The serialization framework would just take the data entry
> and (de)serialize it. The serialization framework would use the type
> catalogue to (de)serialize the data, like we currently do with Pdx. The
> order of fields for the data is specified and we know how to
> (de)serialize the data.
>
> Improving the current JSONFormatter was really a start, a way how we can
> improve the definition and usage of other, non-POJO like, structures. We
> are currently facing the following problems:
>
>   * Too many types created due to inconsistently structured JSON documents
>   * DateTime fields incorrectly processed due to missing the time
> component on import. (Import/Export)
>   * Decimal field formatting
>
> @jake, I like the idea of having FieldReadable interface (we can work on
> the naming though). Then we can start getting some conformity around how
> we access data regardless of what type of object stored.
>
>
> On 1/4/17 07:14, William Markito Oliveira wrote:
> > I think bson already stores the field names within the serialized data
> > values, which is indeed more generic but would of course take more space.
> >
> > These conversations are very interesting, specially considering how many
> > popular serialization formats exists out there (Parquet, Avro, Protobuf,
> > etc...) but I'm not sure the serialization itself was the main thing with
> > Udo's proposal and more the problem that today JSONFormatter + PDXTypes
> is
> > the only way to do it and it could cause the "explosion of types" on
> > unstructured data.
> >
> > Seems to me that fixing the JSONFormatter to be smarter about it is a
> quick
> > path but it would not address the whole picture of making serialization
> > options modular in Geode which could be it's own new proposal as well.
> >   Just a thought.
> >
> > On Tue, Jan 3, 2017 at 7:21 PM, Jacob Barrett
> wrote:
> >
> >> I don't know that I would be concerned with optimization of unstructured
> >> data from the start. Given that the data is unstructured it means that
> it
> >> can be restructured at a later time. You could have a lazy task running
> on
> >> the server the 

[jira] [Commented] (GEODE-1407) CI Failure: ReconnectDUnitTest.testReconnectALocator

[ASF GitHub Bot (JIRA)]

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

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

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/313#discussion_r94819019
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java ---
@@ -534,41 +532,35 @@ public Object call() throws CacheException {
 Cache cache = getCache();
 Region myRegion = cache.getRegion("root/myRegion");
 myRegion.put("MyKey1", "MyValue1");
-// myRegion.put("Mykey2", "MyValue2");
 return savedSystem.getDistributedMember();
   }
 };
 vm1.invoke(create1);
 
-
 try {
-
   dm = getDMID(vm0);
   createGfshWaitingThread(vm0);
   forceDisconnect(vm0);
   newdm = waitForReconnect(vm0);
   assertGfshWaitingThreadAlive(vm0);
 
-  vm0.invoke(new SerializableRunnable("check for running locator") {
-public void run() {
-  WaitCriterion wc = new WaitCriterion() {
-public boolean done() {
-  return Locator.getLocator() != null;
-}
-
-public String description() {
-  return "waiting for locator to restart";
-}
-  };
-  Wait.waitForCriterion(wc, 3, 1000, false);
+  boolean running = (Boolean) vm0.invoke(new 
SerializableCallable("check for running locator") {
--- End diff --

This can be written as a "proper" Lambda if you wanted to continue the 
refactor. vm0.invoke("check for running locator", () -> {...});


> CI Failure: ReconnectDUnitTest.testReconnectALocator
> 
>
> Key: GEODE-1407
> URL: https://issues.apache.org/jira/browse/GEODE-1407
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Sai Boorlagadda
>  Labels: ci
>
> Related to GEODE-598. Opening a new one.
> {noformat}
> Error Message
> junit.framework.AssertionFailedError: expected the restarted member to be 
> hosting a running locator
> Stacktrace
> junit.framework.AssertionFailedError: expected the restarted member to be 
> hosting a running locator
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> com.gemstone.gemfire.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:548)
>   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 junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   

[GitHub] geode pull request #313: [GEODE-1407] Change a FlakyTest to distributedTest.

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/313#discussion_r94819019
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java ---
@@ -534,41 +532,35 @@ public Object call() throws CacheException {
 Cache cache = getCache();
 Region myRegion = cache.getRegion("root/myRegion");
 myRegion.put("MyKey1", "MyValue1");
-// myRegion.put("Mykey2", "MyValue2");
 return savedSystem.getDistributedMember();
   }
 };
 vm1.invoke(create1);
 
-
 try {
-
   dm = getDMID(vm0);
   createGfshWaitingThread(vm0);
   forceDisconnect(vm0);
   newdm = waitForReconnect(vm0);
   assertGfshWaitingThreadAlive(vm0);
 
-  vm0.invoke(new SerializableRunnable("check for running locator") {
-public void run() {
-  WaitCriterion wc = new WaitCriterion() {
-public boolean done() {
-  return Locator.getLocator() != null;
-}
-
-public String description() {
-  return "waiting for locator to restart";
-}
-  };
-  Wait.waitForCriterion(wc, 3, 1000, false);
+  boolean running = (Boolean) vm0.invoke(new 
SerializableCallable("check for running locator") {
--- End diff --

This can be written as a "proper" Lambda if you wanted to continue the 
refactor. vm0.invoke("check for running locator", () -> {...});


---
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-2266) index creation with value constraint of PdxInstance should not validate indexed field

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-2266:


This chunk of code in executioncontext allows the un value-constrained non 
alias index to be created

{code}
if (!TypeUtils.OBJECT_TYPE.equals(itr.getElementType())
&& itr.containsProperty(name, numArgs, mustBeMethod)) {
  hits.add(itr);
} else if (TypeUtils.OBJECT_TYPE.equals(itr.getElementType())) {
  if (foundOneUnknown) {
oneUnknown = null; // more than one
  } else {
foundOneUnknown = true;
oneUnknown = itr;
  }
}
{code}

> index creation with value constraint of PdxInstance should not validate 
> indexed field
> -
>
> Key: GEODE-2266
> URL: https://issues.apache.org/jira/browse/GEODE-2266
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> When creating an index on a region with a value constraint, we validate that 
> the indexed field exists as a value for the value constraint object type.  It 
> makes sense to validate this field exists on a user domain object as the 
> index would be useless if the field did not exist for the only object type 
> for this region.  However if the value constraint is a PdxInstance, we should 
> not validate this field exists and instead treat it similar to a non value 
> constrained region.  This is because the PdxInstance can represent any object 
> type and the field is not specifically a field on the PdxInstance object but 
> rather a field on the pdx serialized object.



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

[jira] [Resolved] (GEODE-2182) Possible race condition when estimating index size and an entry is destroyed

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2182.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Possible race condition when estimating index size and an entry is destroyed
> 
>
> Key: GEODE-2182
> URL: https://issues.apache.org/jira/browse/GEODE-2182
> Project: Geode
>  Issue Type: Bug
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.1.0
>
>
> There is a possible race condition when estimating size of an index and an 
> entry is destroyed.  This doesnt get caught and instead percolates to the top 
> as an EntryDestroyedException.
> A quick work around would be to catch the exception and return 0, this may 
> lead to an inefficient lookup but the results would be correct.
> The better alternative would be to continue iterating if possible.



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

Fwd: Build failed in Jenkins: Geode-nightly #707

[Kirk Lund]

The two failures are in SharedConfigurationUsingDirDUnitTest. I'll look
into these.

-- Forwarded message --
From: Apache Jenkins Server 
Date: Thu, Jan 5, 2017 at 7:44 AM
Subject: Build failed in Jenkins: Geode-nightly #707
To: dev@geode.apache.org, kmil...@pivotal.io, upthewatersp...@apache.org,
huyn...@gmail.com, jil...@pivotal.io, ukohlme...@pivotal.io,
gz...@pivotal.io, bschucha...@pivotal.io


See 

Changes:

[bschuchardt] spotless fixes

[upthewaterspout] GEODE-165: Fixing the eclipse dependence on the grammar
source

[ukohlmeyer] GEODE-1294: Added test to confirm default http mutual
authentication

[gzhou] GEODE-2241: filter out duplicate entries for list index and run
search

--
[...truncated 699 lines...]
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote:  uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest

Re: The right way to remove a region's cache listener?

[Kirk Lund]

This is the perfect example of something that is very easy to do in Java
API but becomes overly complex in GFSH.

In the Java API, you can instantiate as many instances of the same
CacheListener class as you want, add them and then remove that specific
instance by passing it in to  public void removeCacheListener(CacheListener
cl) on Region (specifically org.apache.geode.cache.AttributesMutator).
Translating that level of complexity to GFSH commands results in an
explosion of options and reference ids.

For example, if I add the same CacheListener class 3 times, then 1st one is
reference id 1, 2nd is reference id 2, etc (or zero-based if you prefer).
The amount of work required to add that in probably isn't worth it for two
reasons: 1) it's probably not that common of a use case, 2) the user could
instead write a Function or custom mbean that is deployed to the cache
server that'll keep references to the CacheListeners and handle calls to
addCacheListener and removeCacheListener for you. For that matter, you
could deploy a custom GFSH command that then triggers the addCacheListener
and removeCacheListener calls in a deployed Function. Given the ability to
do this pretty easily in a customized way is probably better than trying to
make the command overly flexible (which translates to overly complex).

I would favor improving the docs and blogging new articles that provide
details on how the user can plugin their own GFSH commands and mbeans.


On Thu, Jan 5, 2017 at 7:57 AM, Deepak Dixit 
wrote:

> I would like to suggest, adding "add-cache-listener" option in addition to
> "remove-cache-listener."
> As adding listeners is as difficult as removing when doing alter region.
>
> So alter region will have following options,
>
> 1) add-cache-listener - Will add provided cache listener to existing list.
> 2) remove-cache-listener - Will remove provided cache listeners. (Here we
> may consider passing empty list will remove all listeners)
>
> And old option of cache-listeners will be removed to eliminate confusion.
>
> On Thu, Jan 5, 2017 at 5:51 PM, Zhang Xiawei 
> wrote:
>
> > Not sure whether I misunderstand/miss something or not, but isn't it
> > possible that you have multiple instances of the same type of
> > CacheListener? like 2 of ListenerTypeA and 3 of ListenerTypeB, so either
> > way shown below modifies at a "category" level?
> >
> > -Xiawei
> >
> > > On 5 Jan 2017, at 1:25 AM, Anthony Baker  wrote:
> > >
> > > Another consideration is that gfsh commands should be easily
> scriptable,
> > IMO.
> > >
> > > If I want to remove just one of the N listeners using this approach, I
> > would need to acquire the list of existing listeners, remove the
> deselected
> > listener, format the list, then pass it to this command.  Is there a way
> to
> > do this in one simple command?
> > >
> > > Anthony
> > >
> > >> On Jan 3, 2017, at 11:08 AM, Kirk Lund  wrote:
> > >>
> > >> +1 I'm for the approach you're proposing. As long as it's documented
> in
> > >> user docs (it's not currently) then this provides a straightforward
> use
> > of
> > >> the existing gfsh syntax without introducing too many new command
> > options.
> > >>
> > >> Create the region with two cache listeners:
> > >> $ create region --name=data
> > >> --cache-listener="my.package.ListenerTypeA,my.package.ListenerTypeB"
> > >>
> > >> Change my mind and decide to remove one of the cache listeners:
> > >> $ alter region --name=data --cache-listener="my.package.
> ListenerTypeB"
> > >>
> > >> -Kirk
> > >>
> > >>
> > >>> On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> > wrote:
> > >>>
> > >>> Is this an intuitive User Experience?
> > >>>
> > >>> Given these two classes:
> > >>>
> > >>> public class ListenerTypeA extends CacheListenerAdapter implements
> > >>> Declarable
> > >>>
> > >>> and
> > >>>
> > >>> public class ListenerTypeB extends CacheListenerAdapter implements
> > >>> Declarable
> > >>>
> > >>> And they are programmatically added to a region:
> > >>>
> > >>> CacheListener listener1 = new ListenerTypeA();
> > >>>
> > >>> CacheListener listener2 = new ListenerTypeB();
> > >>>
> > >>> Region region = cache. > >>> Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> PROXY)
> > >>>
> > >>>   .initCacheListeners(new CacheListener[]{listener1,
> > >>> listener2}).create("regionA");
> > >>>
> > >>>
> > >>> What would the expected gfsh command to remove them.  Should we
> remove
> > the
> > >>> listeners via omission?  For example, removing listener1 might be:
> > >>>
> > >>> alter region --name=data --cache-listener='my.package.ListenerTypeB'
> > >>>
> > >>>
> > >>> By only listing the listeners I want...either to keep and/or to add,
> > >>> listener1 which is a ListenerTypeA, would be removed.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> >  On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling 
> > 

[jira] [Resolved] (GEODE-2155) Auto-reconnect fails with NPE

[Bruce Schuchardt (JIRA)]

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

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

> Auto-reconnect fails with NPE
> -
>
> Key: GEODE-2155
> URL: https://issues.apache.org/jira/browse/GEODE-2155
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> The symptom of this bug is
> {noformat}
> [severe 2016/11/29 15:55:42.982 PST gemfire1_carlos_13646  
> tid=0x4d] Unexpected exception while booting membership services
> java.lang.NullPointerException
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.establishLocalAddress(JGroupsMessenger.java:446)
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:342)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:153)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2688)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2521)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:989)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4299)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1530)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$18(GMSMembershipManager.java:2550)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is caused by a previous attempt to recreate the cache in a "reconnect 
> thread" encountered problems
> {noformat}
> [warning 2016/11/29 15:54:42.943 PST gemfire1_carlos_13646  
> tid=0x4d] Exception occurred while trying to create the cache during reconnect
> org.apache.geode.cache.CacheXmlException: While reading Cache XML null. Class 
> "tx.TxLoader" is not an instance of Declarable.
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.createDeclarable(CacheXmlParser.java:1946)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endCacheLoader(CacheXmlParser.java:1997)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:2964)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3379)
>   at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
>   at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:857)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1783)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2970)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
>   at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
>   at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
>   at 
> 

[jira] [Commented] (GEODE-2155) Auto-reconnect fails with NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2155:


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

GEODE-2155 Auto-reconnect fails with NPE

I created a test to reproduce the problem by introducing a non-Declarable
cache listener and then initiating a forced-disconnect.  cache.xml is
generated and when it's used to rebuild the cache a CacheXmlException
is thrown, reliably reproducing the problem.

The fix is to simply catch the CacheXmlException in
InternalDistributedSystem.reconnect() and terminate reconnection attempt


> Auto-reconnect fails with NPE
> -
>
> Key: GEODE-2155
> URL: https://issues.apache.org/jira/browse/GEODE-2155
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> The symptom of this bug is
> {noformat}
> [severe 2016/11/29 15:55:42.982 PST gemfire1_carlos_13646  
> tid=0x4d] Unexpected exception while booting membership services
> java.lang.NullPointerException
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.establishLocalAddress(JGroupsMessenger.java:446)
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:342)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:153)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2688)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2521)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:989)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4299)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1530)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$18(GMSMembershipManager.java:2550)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is caused by a previous attempt to recreate the cache in a "reconnect 
> thread" encountered problems
> {noformat}
> [warning 2016/11/29 15:54:42.943 PST gemfire1_carlos_13646  
> tid=0x4d] Exception occurred while trying to create the cache during reconnect
> org.apache.geode.cache.CacheXmlException: While reading Cache XML null. Class 
> "tx.TxLoader" is not an instance of Declarable.
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.createDeclarable(CacheXmlParser.java:1946)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endCacheLoader(CacheXmlParser.java:1997)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:2964)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3379)
>   at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
>   at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:857)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1783)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2970)
>   at 
> 

Re: The right way to remove a region's cache listener?

[Deepak Dixit]

I would like to suggest, adding "add-cache-listener" option in addition to
"remove-cache-listener."
As adding listeners is as difficult as removing when doing alter region.

So alter region will have following options,

1) add-cache-listener - Will add provided cache listener to existing list.
2) remove-cache-listener - Will remove provided cache listeners. (Here we
may consider passing empty list will remove all listeners)

And old option of cache-listeners will be removed to eliminate confusion.

On Thu, Jan 5, 2017 at 5:51 PM, Zhang Xiawei 
wrote:

> Not sure whether I misunderstand/miss something or not, but isn't it
> possible that you have multiple instances of the same type of
> CacheListener? like 2 of ListenerTypeA and 3 of ListenerTypeB, so either
> way shown below modifies at a "category" level?
>
> -Xiawei
>
> > On 5 Jan 2017, at 1:25 AM, Anthony Baker  wrote:
> >
> > Another consideration is that gfsh commands should be easily scriptable,
> IMO.
> >
> > If I want to remove just one of the N listeners using this approach, I
> would need to acquire the list of existing listeners, remove the deselected
> listener, format the list, then pass it to this command.  Is there a way to
> do this in one simple command?
> >
> > Anthony
> >
> >> On Jan 3, 2017, at 11:08 AM, Kirk Lund  wrote:
> >>
> >> +1 I'm for the approach you're proposing. As long as it's documented in
> >> user docs (it's not currently) then this provides a straightforward use
> of
> >> the existing gfsh syntax without introducing too many new command
> options.
> >>
> >> Create the region with two cache listeners:
> >> $ create region --name=data
> >> --cache-listener="my.package.ListenerTypeA,my.package.ListenerTypeB"
> >>
> >> Change my mind and decide to remove one of the cache listeners:
> >> $ alter region --name=data --cache-listener="my.package.ListenerTypeB"
> >>
> >> -Kirk
> >>
> >>
> >>> On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> wrote:
> >>>
> >>> Is this an intuitive User Experience?
> >>>
> >>> Given these two classes:
> >>>
> >>> public class ListenerTypeA extends CacheListenerAdapter implements
> >>> Declarable
> >>>
> >>> and
> >>>
> >>> public class ListenerTypeB extends CacheListenerAdapter implements
> >>> Declarable
> >>>
> >>> And they are programmatically added to a region:
> >>>
> >>> CacheListener listener1 = new ListenerTypeA();
> >>>
> >>> CacheListener listener2 = new ListenerTypeB();
> >>>
> >>> Region region = cache. >>> Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
> >>>
> >>>   .initCacheListeners(new CacheListener[]{listener1,
> >>> listener2}).create("regionA");
> >>>
> >>>
> >>> What would the expected gfsh command to remove them.  Should we remove
> the
> >>> listeners via omission?  For example, removing listener1 might be:
> >>>
> >>> alter region --name=data --cache-listener='my.package.ListenerTypeB'
> >>>
> >>>
> >>> By only listing the listeners I want...either to keep and/or to add,
> >>> listener1 which is a ListenerTypeA, would be removed.
> >>>
> >>>
> >>>
> >>>
> >>>
>  On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling 
> wrote:
> 
>  I'm looking at GEODE-2236
>   and protecting
> >>> against
>  the NPE is trivial.  But the question is, what is the right way to do
>  this?  What is the syntax people would expect to use?
> 
> 
>  What if there are multiple listeners and you wanted to delete one or
> more
>  of them?
> >
>



-- 
From:

Deepak D Dixit
deepakdixit2...@gmail.com
+919028507537

Build failed in Jenkins: Geode-nightly #707

[Apache Jenkins Server]

See 

Changes:

[bschuchardt] spotless fixes

[upthewaterspout] GEODE-165: Fixing the eclipse dependence on the grammar source

[ukohlmeyer] GEODE-1294: Added test to confirm default http mutual 
authentication

[gzhou] GEODE-2241: filter out duplicate entries for list index and run search

--
[...truncated 699 lines...]
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest
:geode-web:flakyTest
:geode-web:integrationTest
:geode-web-api:assemble
:geode-web-api:compileTestJava UP-TO-DATE
:geode-web-api:processTestResources UP-TO-DATE
:geode-web-api:testClasses UP-TO-DATE
:geode-web-api:checkMissedTests UP-TO-DATE
:geode-web-api:spotlessJavaCheck
:geode-web-api:spotlessCheck
:geode-web-api:test UP-TO-DATE
:geode-web-api:check
:geode-web-api:build
:geode-web-api:distributedTest UP-TO-DATE
:geode-web-api:flakyTest UP-TO-DATE

[GitHub] geode pull request #330: [GEODE-2227] AutoSerializableJUnitTest.testMultiple...

[metatype]

Github user metatype commented on a diff in the pull request:

https://github.com/apache/geode/pull/330#discussion_r94783782
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/pdx/AutoSerializableJUnitTest.java ---
@@ -1291,7 +1289,8 @@ public void testMultipleClassLoaders() throws 
Exception {
 List urls = new ArrayList();
 String classPathStr = System.getProperty("java.class.path");
 if (classPathStr != null) {
-  String[] cpList = classPathStr.split(":");
+  String[] cpList =
--- End diff --

You can avoid the ternary operator by using 
`System.getProperty("path.separator")`.


---
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-2227) AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on a diff in the pull request:

https://github.com/apache/geode/pull/330#discussion_r94783782
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/pdx/AutoSerializableJUnitTest.java ---
@@ -1291,7 +1289,8 @@ public void testMultipleClassLoaders() throws 
Exception {
 List urls = new ArrayList();
 String classPathStr = System.getProperty("java.class.path");
 if (classPathStr != null) {
-  String[] cpList = classPathStr.split(":");
+  String[] cpList =
--- End diff --

You can avoid the ternary operator by using 
`System.getProperty("path.separator")`.


> AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError 
> on Windows
> ---
>
> Key: GEODE-2227
> URL: https://issues.apache.org/jira/browse/GEODE-2227
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>Assignee: Kai Jiang
>  Labels: IntegrationTest, Windows
>
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.geode.pdx.AutoSerializableJUnitTest.testMultipleClassLoaders(AutoSerializableJUnitTest.java:1275)
>   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.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: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 
> 

[jira] [Created] (GEODE-2270) Need API to call gfsh and get results dynamically from code

[Wes Williams (JIRA)]

Wes Williams created GEODE-2270:
---

 Summary: Need API to call gfsh and get results dynamically from 
code
 Key: GEODE-2270
 URL: https://issues.apache.org/jira/browse/GEODE-2270
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Wes Williams
 Fix For: 1.1.0


GIVEN:
1) The GfshParser and CommandResult are internal classes.
2) CommandResult returns headings, line.separator's and UI concerns along with 
the answer

WHEN:
I pass a gfsh command into a public gfsh API from code

THEN:
I get back an XML representation of the core results without the headings, 
line.separator's and UI concerns

EXAMPLE (idea node and not actual implementation):
WHEN:
String gfshResults = gfshPublicAPI("list regions");
return gfshResults;

String gfshPublicAPI(String gfshCommand) {
ParseResult parseResult = gfshParser.parse(gfshCommand);
XmlResult results = (XmlResult) parseResult.getMethod()+"Xml"
  .invoke(parseResult.getInstance(), parseResult.getArguments())
   return results;
}

CommandResult gfshInternalAPI(String gfshCommand) {
ParseResult parseResult = gfshParser.parse(gfshCommand);
CommandResult results = (CommandResult) parseResult.getMethod()
  .invoke(parseResult.getInstance(), parseResult.getArguments())
   return results;
}




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

[jira] [Created] (GEODE-2269) It seems the gfsh "remove" command cannot remove r...

[Gregory Green (JIRA)]

Gregory Green created GEODE-2269:


 Summary: It seems the gfsh "remove" command cannot remove r...
 Key: GEODE-2269
 URL: https://issues.apache.org/jira/browse/GEODE-2269
 Project: Geode
  Issue Type: Improvement
Reporter: Gregory Green


It seems the gfsh "remove" command cannot remove region entries with a 0 length 
string key.

gfsh>query --query="select toString().length() from /Recipient.keySet()"

Result : true
startCount : 0
endCount   : 20
Rows   : 3

Result
--
0
2
5


gfsh>remove --region=/Recipient --key=""
Message : Key is either empty or Null
Result  : false

gfsh>remove --region=/Recipient --key="''"
Message : Key is either empty or Null
Result  : false





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

[jira] [Assigned] (GEODE-2227) AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError on Windows

[Kai Jiang (JIRA)]

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

Kai Jiang reassigned GEODE-2227:


Assignee: Kai Jiang

> AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError 
> on Windows
> ---
>
> Key: GEODE-2227
> URL: https://issues.apache.org/jira/browse/GEODE-2227
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>Assignee: Kai Jiang
>  Labels: IntegrationTest, Windows
>
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.geode.pdx.AutoSerializableJUnitTest.testMultipleClassLoaders(AutoSerializableJUnitTest.java:1275)
>   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.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: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 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> 

[jira] [Commented] (GEODE-2227) AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError on Windows

[ASF GitHub Bot (JIRA)]

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

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

GitHub user vectorijk opened a pull request:

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

[GEODE-2227] AutoSerializableJUnitTest.testMultipleClassLoaders fails on 
Windows

Parsing the path of classes is not correctly on Windows. The path of 
library classes on Windows is split by semicolon instead of colon. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vectorijk/geode GEODE-2227

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #330


commit 6f02008a1930ebf448d3387a59eccd57c2ce7ded
Author: Kai Jiang 
Date:   2017-01-05T12:11:26Z

GEODE-2227

AutoSerializableJUnitTest.testMultipleClassLoaders fails on Windows




> AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError 
> on Windows
> ---
>
> Key: GEODE-2227
> URL: https://issues.apache.org/jira/browse/GEODE-2227
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>  Labels: IntegrationTest, Windows
>
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.geode.pdx.AutoSerializableJUnitTest.testMultipleClassLoaders(AutoSerializableJUnitTest.java:1275)
>   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.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: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 

[GitHub] geode pull request #330: [GEODE-2227] AutoSerializableJUnitTest.testMultiple...

[vectorijk]

GitHub user vectorijk opened a pull request:

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

[GEODE-2227] AutoSerializableJUnitTest.testMultipleClassLoaders fails on 
Windows

Parsing the path of classes is not correctly on Windows. The path of 
library classes on Windows is split by semicolon instead of colon. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vectorijk/geode GEODE-2227

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #330


commit 6f02008a1930ebf448d3387a59eccd57c2ce7ded
Author: Kai Jiang 
Date:   2017-01-05T12:11:26Z

GEODE-2227

AutoSerializableJUnitTest.testMultipleClassLoaders fails on Windows




---
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.
---