[jira] [Closed] (GEODE-2490) Tombstone messages are getting processed inline

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar closed GEODE-2490.
---

> Tombstone messages are getting processed inline
> ---
>
> Key: GEODE-2490
> URL: https://issues.apache.org/jira/browse/GEODE-2490
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> Tombstone:
> As part of consistency checking, when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone.
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently the tombstone message sent for replicas are getting processed 
> in-line. Based on the number of nodes in the cluster, this may take long time 
> to process, impacting other cache operation that required to be processed 
> in-line. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2490) Tombstone messages are getting processed inline

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-2490:

Fix Version/s: 1.2.0

> Tombstone messages are getting processed inline
> ---
>
> Key: GEODE-2490
> URL: https://issues.apache.org/jira/browse/GEODE-2490
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> Tombstone:
> As part of consistency checking, when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone.
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently the tombstone message sent for replicas are getting processed 
> in-line. Based on the number of nodes in the cluster, this may take long time 
> to process, impacting other cache operation that required to be processed 
> in-line. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2490) Tombstone messages are getting processed inline

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2490.
-
Resolution: Fixed

> Tombstone messages are getting processed inline
> ---
>
> Key: GEODE-2490
> URL: https://issues.apache.org/jira/browse/GEODE-2490
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>
> Tombstone:
> As part of consistency checking, when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone.
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently the tombstone message sent for replicas are getting processed 
> in-line. Based on the number of nodes in the cluster, this may take long time 
> to process, impacting other cache operation that required to be processed 
> in-line. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2489) Tombstone message with keys are sent to peer partitioned region nodes even though no clinets are registered

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar updated GEODE-2489:

Fix Version/s: 1.2.0

> Tombstone message with keys are sent to peer partitioned region nodes even 
> though no clinets are registered
> ---
>
> Key: GEODE-2489
> URL: https://issues.apache.org/jira/browse/GEODE-2489
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> Tombstone:
> As part of consistency checking,  when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone. 
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently tombstone messages meant for clients that have all the keys removed 
> are getting sent to peer PR nodes even though no clients are registered on 
> those peers.
> Based on the number tombstone keys processed (by default 10) this could 
> be large message sent to peer node which could impact the performance of the 
> system/cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2489) Tombstone message with keys are sent to peer partitioned region nodes even though no clinets are registered

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2489.
-
Resolution: Fixed

> Tombstone message with keys are sent to peer partitioned region nodes even 
> though no clinets are registered
> ---
>
> Key: GEODE-2489
> URL: https://issues.apache.org/jira/browse/GEODE-2489
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>
> Tombstone:
> As part of consistency checking,  when an entry is destroyed, the member 
> temporarily retains the entry to detect possible conflicts with operations 
> that have occurred. The retained entry is referred to as a tombstone. 
> When tombstones are removed, tombstone messages are sent to region replicas; 
> and in case of Partitioned Region (PR) messages are also sent to peer region 
> nodes for client events.
> Currently tombstone messages meant for clients that have all the keys removed 
> are getting sent to peer PR nodes even though no clients are registered on 
> those peers.
> Based on the number tombstone keys processed (by default 10) this could 
> be large message sent to peer node which could impact the performance of the 
> system/cluster.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: export logs and stats

[Swapnil Bawaskar]

+1 for restricting the file extensions and looking at what the user has
defined.

On Tue, Feb 28, 2017 at 4:46 PM Jinmei Liao  wrote:

> Yeah, before we were simply looking at System.getProperty("user.dir") to
> get all the logs/stats, now I think we should use whatever user defined in
> the config file and do a getParent to get the parent directory to search
> for the files.
>
> On Tue, Feb 28, 2017 at 4:34 PM, Dan Smith  wrote:
>
> > I think maybe I didn't quite understand the original proposal. Are you
> > saying you won't even look at the directory or filename the user
> specifies,
> > but just grab all the files that happen to be in the working directory
> and
> > end in .log? I don't think that's going to do the right thing for most
> > users.
> >
> > Very commonly users do direct their logs to separate directory, at least
> a
> > subdirectory of their working directory. And they often put all of their
> > logs into that directory - application logs, gemfire logs, etc. So I
> think
> > you really do need to look at the directory and filename they are
> > specifying.
> >
> > Now, if you are just saying that their filename has to end in .log, that
> > seems like a reasonable restriction. It seems like maybe we already have
> > that restriction if you're hitting an IndexOutOfBoundError.
> >
> > -Dan
> >
> > On Tue, Feb 28, 2017 at 4:20 PM, Jinmei Liao  wrote:
> >
> > > Darrel, it seems if user defines a log file to be simply "serverLog" (a
> > > filename with no "."), when rolling over the log file once file size is
> > > reached, we get a IndexOutOfBoundError when it's trying to figure out
> > > what's the rolled-over filename should be.
> > >
> > > And if user defines a log file name to be "server.log.gz", when rolling
> > > over, the new filename seems to be "server.log_01_01.gz". Does not look
> > > like we handle the ".gz' suffix correctly. For now, we do want to
> enforce
> > > the log/stats filename ends with appropriate suffix.
> > >
> > > On Tue, Feb 28, 2017 at 3:16 PM, Darrel Schneider <
> dschnei...@pivotal.io
> > >
> > > wrote:
> > >
> > > > It sounds like you will pick up any file in the working directory
> that
> > > ends
> > > > with ".log" or ".log.gz".
> > > > But what if the geode server is sharing a directory with something
> else
> > > > that is also writing files with these extensions?
> > > > Or if multiple geode servers are running in the same directory?
> > > > I think it would be better to use the configured log file name and
> stat
> > > > archive name and use that to find the logs and stats to gather. The
> > > rolling
> > > > code has already been written that will find all the existing logs
> and
> > > > stats. In any bugs in that code need to be fixed since it would break
> > the
> > > > code that removes old files based on disk space. So it seems like you
> > > > should be able to use this same code to get a list of the files to
> > copy.
> > > >
> > > >
> > > > On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith 
> wrote:
> > > >
> > > > > I'm a bit confused by (1). Isn't it actually more complicated for
> you
> > > to
> > > > > restrict log collection to a relative path? Why not just look for
> log
> > > > files
> > > > > no matter where they are written to? I also don't really follow the
> > > > > argument about why a user that writes to /var/logs is not going to
> > want
> > > > to
> > > > > use this command. Won't all users want to be able to gather their
> > logs
> > > > > using this command?
> > > > >
> > > > > 2 seems reasonable. It seems like we should restrict the file names
> > if
> > > we
> > > > > are going to have this limitation.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao 
> > > wrote:
> > > > >
> > > > > > Hello community,
> > > > > >
> > > > > > We are currently trying to improve what "export logs" should do.
> > > > > Currently
> > > > > > export logs only export the logs(filtered by logLevel and start
> and
> > > end
> > > > > > date) to each individual member's file system. We want to make
> all
> > > the
> > > > > > member's logs exported to a central location  and if you are
> > > connecting
> > > > > > using http, it will be exported to your local file system. This
> is
> > to
> > > > > > facilitate gathering logs in the cloud environment.
> > > > > >
> > > > > > That said, for the first round of implementation, we would like
> to
> > > > impose
> > > > > > these restrictions to this command:
> > > > > > 1) it will only look for the logs/stats in each members working
> > > > directory
> > > > > > only.
> > > > > > 2) it will only look for files that ends with .log, .log.gz, .gfs
> > or
> > > > > > .gfs.gz.
> > > > > >
> > > > > > Background for 1): if you started your locator/server with
> > "log-file"
> > > > or
> > > > > > "statistics-archive-file" with an absolute path, it will write
> > these
> > > > > files
> > > 

Re: gfsh> export cluster-configuration - Reason: null

[Jinmei Liao]

It is the correct syntax, I just tried it on the tip of develop branch. I
know we have tests that covers export cluster-configuration in the
pipeline. Please do file a ticket with the logs.

gfsh>export cluster-configuration --zip-file-name=test.zip

Downloading cluster configuration : /Users/jiliao/my_geode/tmp/test.zip

On Tue, Feb 28, 2017 at 10:36 PM, Real Wes  wrote:

> Is this proper syntax in Geode 1.1.0?   If so, let me know and I’ll file a
> jira...
>
> gfsh>export cluster-configuration --zip-file-name=cluster.zip
> Could not process command due to GemFire error. Error while processing
> command  Reason :
> null
>
>
> Thanks,
> Wes
>
>
> > On Mar 1, 2017, at 12:24 AM, Jinmei Liao  wrote:
> >
> > We have multiple jira tickets on this waiting to be fixed:
> > https://issues.apache.org/jira/browse/GEODE-1597
> > https://issues.apache.org/jira/browse/GEODE-2249
> >
> >
> > On Tue, Feb 28, 2017 at 9:16 PM, Real Wes 
> wrote:
> >
> >> This works in Geode 1.1.0 where GemFire 8 failed:
> >>
> >> gfsh> create region --name=Testxxx --type=PARTITION_REDUNDANT_HEAP_LRU
> >> --badProperty=badValue
> >>
> >>
> >> Is ignoring bad properties by design?  Or a bug?
> >>
> >> Thanks,
> >> Wes Williams
> >>
> >>
> >>
> >
> >
> > --
> > Cheers
> >
> > Jinmei
>
>


-- 
Cheers

Jinmei

Re: Gfsh> Create regions with bad property values?

[Jinmei Liao]

We have multiple jira tickets on this waiting to be fixed:
https://issues.apache.org/jira/browse/GEODE-1597
https://issues.apache.org/jira/browse/GEODE-2249


On Tue, Feb 28, 2017 at 9:16 PM, Real Wes  wrote:

> This works in Geode 1.1.0 where GemFire 8 failed:
>
> gfsh> create region --name=Testxxx --type=PARTITION_REDUNDANT_HEAP_LRU
> --badProperty=badValue
>
>
> Is ignoring bad properties by design?  Or a bug?
>
> Thanks,
> Wes Williams
>
>
>


-- 
Cheers

Jinmei

Gfsh> Create regions with bad property values?

[Real Wes]

This works in Geode 1.1.0 where GemFire 8 failed:

gfsh> create region --name=Testxxx --type=PARTITION_REDUNDANT_HEAP_LRU 
--badProperty=badValue


Is ignoring bad properties by design?  Or a bug?

Thanks,
Wes Williams

Re: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Jared Stewart]

Thanks for the tips, Kirk! I think #2 is something I ought to do more often.

On Feb 28, 2017 5:59 PM, "Kirk Lund"  wrote:

> Everything is building fine now, so I'm going to revert that commit.
>
> Avinash, go ahead and recommit it after the issue with the sub-class
> parameterization is fixed and it passes review and precheckin.
>
> I don't know of any way to make JUnit Parameterized work with JUnitParams,
> and I'd recommend not trying to do that.
>
> Here's a few generalized JUnit test recommendations. One or two might be of
> help in this case:
>
> 1) JUnitParams seems more flexible and parameterizes at the test method
> level, whereas Parameterized parameterizes at the class level which forces
> all of the test methods to repeat with new parameters.
>
> 2) I favor splitting tests. If you have a test method that requires
> different setUp/tearDown or parameterization and it no longer fits well,
> then splitting it up into multiple test classes is probably a good idea.
>
> 3) I've seen subclassing of tests be horribly abused, so I'd recommend
> avoiding this whenever possible. It's frequently better to use a custom
> JUnit Rule or even to repeat code in setUp/tearDown.
>
> 4) As an addendum to #3, don't be tempted to have one test class
> instantiate another test class and invoke methods on it. This just creates
> horrible spaghetti.
>
> On Tue, Feb 28, 2017 at 11:29 AM, Mark Bretl  wrote:
>
> > There is an AWS outage right now, not sure if that is affecting the
> Gradle
> > plugin site...
> >
> > --Mark
> >
> > On Tue, Feb 28, 2017 at 10:53 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > wrote:
> >
> > > I deleted my gradle cache & am also having trouble downloading things
> > >
> > >:buildSrc:build UP-TO-DATE
> > >
> > >FAILURE: Build failed with an exception.
> > >
> > >* What went wrong:
> > >A problem occurred configuring root project 'geode'.
> > > > Could not resolve all dependencies for configuration
> ':classpath'.
> > >> Could not resolve
> > >gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
> > >  Required by:
> > >  :geode:unspecified
> > >   > Could not resolve
> > >gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
> > >  > Could not get resource
> > >'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> > > pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> > > > Could not GET
> > >'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> > > pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> > >Received status code 503 from server: Service Unavailable
> > >etc.
> > >
> > > I'm getting 503s on everything but the initial gradle download.
> > >
> > >
> > > Le 2/28/2017 à 10:40 AM, Avinash Dongre a écrit :
> > >
> > >> I am getting following error while running precheckin.
> > >>
> > >> * Where:
> > >> Build file '/home/ampool/private/geode/java/geode/geode-old-versions/
> bu
> > >> ild.gradle'
> > >> line: 58
> > >>
> > >> * What went wrong:
> > >> Execution failed for task ':geode-old-versions:createGeo
> > >> deClasspathsFile'.
> > >>
> > >>> Could not resolve all dependencies for configuration
> > >>> ':geode-old-versions:
> > >>>
> > >> test110Runtime'.
> > >> > Could not download geode-cq.jar (org.apache.geode:geode-cq:1.
> 1.0)
> > >>> Could not get resource 'https://repo1.maven.org/
> > >> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'.
> > >>   > Could not GET 'https://repo1.maven.org/
> > >> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'. Received
> > >> status
> > >> code 503 from server: Connection timed out
> > >>
> > >>
> > >>
> > >> On Tue, Feb 28, 2017 at 11:06 PM, Avinash Dongre 
> > >> wrote:
> > >>
> > >> It is my mistake.
> > >>>
> > >>> I will revert back my changes for this Test and raise a PR.
> > >>>
> > >>> Thanks
> > >>> Avinash
> > >>>
> > >>>
> > >>> On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt <
> > >>> bschucha...@pivotal.io
> > >>>
> >  wrote:
> >  ClientServerMiscBCDUnitTest is failing due to adongre's commit
> >  yesterday.  A parameterized test was added to a superclass, causing
> >  conflict with the subclass's parameterization of all the
> superclass's
> >  methods
> > 
> > 
> >  java.lang.Exception: Method testProxyRegionClientServerOp should
> have
> > no
> >  parameters
> > 
> >   at org.junit.runners.model.FrameworkMethod.
> validatePublicVoidNo
> >  Arg(FrameworkMethod.java:76)
> >   at org.junit.runners.ParentRunner.
> validatePublicVoidNoArgMethod
> >  s(ParentRunner.java:155)
> >   at org.junit.runners.BlockJUnit4ClassRunner.
> validateTestMethods
> >  (BlockJUnit4ClassRunner.java:208)
> >   at org.junit.runners.BlockJUnit4ClassRunner.
> validateInstanceMet
> >  

Re: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Kirk Lund]

Everything is building fine now, so I'm going to revert that commit.

Avinash, go ahead and recommit it after the issue with the sub-class
parameterization is fixed and it passes review and precheckin.

I don't know of any way to make JUnit Parameterized work with JUnitParams,
and I'd recommend not trying to do that.

Here's a few generalized JUnit test recommendations. One or two might be of
help in this case:

1) JUnitParams seems more flexible and parameterizes at the test method
level, whereas Parameterized parameterizes at the class level which forces
all of the test methods to repeat with new parameters.

2) I favor splitting tests. If you have a test method that requires
different setUp/tearDown or parameterization and it no longer fits well,
then splitting it up into multiple test classes is probably a good idea.

3) I've seen subclassing of tests be horribly abused, so I'd recommend
avoiding this whenever possible. It's frequently better to use a custom
JUnit Rule or even to repeat code in setUp/tearDown.

4) As an addendum to #3, don't be tempted to have one test class
instantiate another test class and invoke methods on it. This just creates
horrible spaghetti.

On Tue, Feb 28, 2017 at 11:29 AM, Mark Bretl  wrote:

> There is an AWS outage right now, not sure if that is affecting the Gradle
> plugin site...
>
> --Mark
>
> On Tue, Feb 28, 2017 at 10:53 AM, Bruce Schuchardt  >
> wrote:
>
> > I deleted my gradle cache & am also having trouble downloading things
> >
> >:buildSrc:build UP-TO-DATE
> >
> >FAILURE: Build failed with an exception.
> >
> >* What went wrong:
> >A problem occurred configuring root project 'geode'.
> > > Could not resolve all dependencies for configuration ':classpath'.
> >> Could not resolve
> >gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
> >  Required by:
> >  :geode:unspecified
> >   > Could not resolve
> >gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
> >  > Could not get resource
> >'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> > pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> > > Could not GET
> >'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> > pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> >Received status code 503 from server: Service Unavailable
> >etc.
> >
> > I'm getting 503s on everything but the initial gradle download.
> >
> >
> > Le 2/28/2017 à 10:40 AM, Avinash Dongre a écrit :
> >
> >> I am getting following error while running precheckin.
> >>
> >> * Where:
> >> Build file '/home/ampool/private/geode/java/geode/geode-old-versions/bu
> >> ild.gradle'
> >> line: 58
> >>
> >> * What went wrong:
> >> Execution failed for task ':geode-old-versions:createGeo
> >> deClasspathsFile'.
> >>
> >>> Could not resolve all dependencies for configuration
> >>> ':geode-old-versions:
> >>>
> >> test110Runtime'.
> >> > Could not download geode-cq.jar (org.apache.geode:geode-cq:1.1.0)
> >>> Could not get resource 'https://repo1.maven.org/
> >> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'.
> >>   > Could not GET 'https://repo1.maven.org/
> >> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'. Received
> >> status
> >> code 503 from server: Connection timed out
> >>
> >>
> >>
> >> On Tue, Feb 28, 2017 at 11:06 PM, Avinash Dongre 
> >> wrote:
> >>
> >> It is my mistake.
> >>>
> >>> I will revert back my changes for this Test and raise a PR.
> >>>
> >>> Thanks
> >>> Avinash
> >>>
> >>>
> >>> On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt <
> >>> bschucha...@pivotal.io
> >>>
>  wrote:
>  ClientServerMiscBCDUnitTest is failing due to adongre's commit
>  yesterday.  A parameterized test was added to a superclass, causing
>  conflict with the subclass's parameterization of all the superclass's
>  methods
> 
> 
>  java.lang.Exception: Method testProxyRegionClientServerOp should have
> no
>  parameters
> 
>   at org.junit.runners.model.FrameworkMethod.validatePublicVoidNo
>  Arg(FrameworkMethod.java:76)
>   at org.junit.runners.ParentRunner.validatePublicVoidNoArgMethod
>  s(ParentRunner.java:155)
>   at org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods
>  (BlockJUnit4ClassRunner.java:208)
>   at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMet
>  hods(BlockJUnit4ClassRunner.java:188)
>   at org.junit.runners.BlockJUnit4ClassRunner.collectInitializati
>  onErrors(BlockJUnit4ClassRunner.java:128)
>   at org.junit.runners.ParentRunner.validate(
> ParentRunner.java:416)
>   at org.junit.runners.ParentRunner.(ParentRunner.java:84)
>   at org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4C
>  lassRunner.java:65)
>   at 

[jira] [Resolved] (GEODE-2538) Lucene query with values should not invoke cache loader

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-2538.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Lucene query with values should not invoke cache loader
> ---
>
> Key: GEODE-2538
> URL: https://issues.apache.org/jira/browse/GEODE-2538
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> Lucene queries use getAll to fetch pages when returning values.
> If an entry is destroyed after the query has found the list of keys, but 
> before the query finds the values, the getAll with trigger a cache loader and 
> reload the value. This may be unexpected behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2538) Lucene query with values should not invoke cache loader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2538:


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

GEODE-2538: Don't deserialize values on the server when getting results

If values on the server are in serialized form, leave them that way and
only deserialize the values on the clients.

This is implemented by having the LuceneGetPageFunction extract the
serialized value and return the results in a new PageResults class,
which handles the deserialization and upwrapping of the value if
necessary.


> Lucene query with values should not invoke cache loader
> ---
>
> Key: GEODE-2538
> URL: https://issues.apache.org/jira/browse/GEODE-2538
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> Lucene queries use getAll to fetch pages when returning values.
> If an entry is destroyed after the query has found the list of keys, but 
> before the query finds the values, the getAll with trigger a cache loader and 
> reload the value. This may be unexpected behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 57175: GEODE-4160: upgrade mortbay-jetty-servlet-api dependency

[Kirk Lund]

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

Review request for geode, Anthony Baker, Jinmei Liao, Jared Stewart, Kevin 
Duling, Ken Howe, and Mark Bretl.


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


Repository: geode


Description
---

Upgrade mortbay-jetty-servlet-api dependency

This is the last upgrade on GEODE-4160 ticket.


Diffs
-

  gradle/dependency-versions.properties aca65fa 

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


Testing
---

precheckin in progress
uiTest passes


Thanks,

Kirk Lund

[jira] [Issue Comment Deleted] (GEODE-2460) Update dependency versions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2460:
-
Comment: was deleted

(was: Commit bc32a76c223d7a2b407fed72595af4056a78e433 in geode's branch 
refs/heads/GEODE-4160-mockito from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc32a76 ]

GEODE-2460: update dependency versions

* com.fasterxml.jackson.core:jackson-annotation:2.8.6
* com.fasterxml.jackson.core:jackson-core:2.8.6
* com.fasterxml.jackson.core:jackson-databind:2.8.6
* com.fasterxml.jackson.module:jackson-module-scala_2.10:2.8.6
* org.eclipse.persistence:javax.persistence:2.1.1
* fix dependency versions in NOTICE files
)

> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (GEODE-2460) Update dependency versions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2460:
-
Comment: was deleted

(was: Commit 23b7de54226a267e2473f0eb426aa88ea91258b6 in geode's branch 
refs/heads/feature/GEODE-2461 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=23b7de5 ]

GEODE-2460: update dependency versions

* com.fasterxml.jackson.core:jackson-annotation:2.8.6
* com.fasterxml.jackson.core:jackson-core:2.8.6
* com.fasterxml.jackson.core:jackson-databind:2.8.6
* com.fasterxml.jackson.module:jackson-module-scala_2.10:2.8.6
* org.eclipse.persistence:javax.persistence:2.1.1
* org.json4s:json4s-ast_2.10:3.5.0
)

> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2558) Upgrade mockito dependency

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2558:
--

We should skip 2.7.11 and upgrade to 2.7.12 which is now out.

1.10.19 (Dec, 2014) <-- current version
2.7.11 (Feb 2017)
2.7.12 (Feb 2017)


> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2558) Upgrade mockito dependency

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2558:


 Summary: Upgrade mockito dependency
 Key: GEODE-2558
 URL: https://issues.apache.org/jira/browse/GEODE-2558
 Project: Geode
  Issue Type: Wish
  Components: build, tests
Reporter: Kirk Lund


Mockito should be upgrade from 1.x to 2.x.

1.10.19 (Dec, 2014) <-- current version
2.7.11 (Feb 2017)

This requires updating Powermock as well.

Changes to dependency-versions.properties:
{noformat}
-mockito-core.version = 1.10.19
+mockito-core.version = 2.7.11
...
-powermock.version = 1.6.6
+powermock.version = 1.7.0RC2
{noformat}

The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after updating 
the APIs to compile, I still see a number of unit tests that use Mockito 
failing. These tests span all of the components in Geode so it's a non-trivial 
upgrade.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2557) Upgrade jna dependency

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2557:
--

4.0.0 (Jul, 2013) <-- current version
4.3.0 (Jan, 2017)

> Upgrade jna dependency
> --
>
> Key: GEODE-2557
> URL: https://issues.apache.org/jira/browse/GEODE-2557
> Project: Geode
>  Issue Type: Wish
>  Components: build, general
>Reporter: Kirk Lund
>
> Upgrade our jna dependency from 4.0.0 to 4.3.0. Dependency name is:
> net.java.dev.jna:jna:4.3.0
> Upgrading this dependency in gradle/dependency-versions.properties:
> -jna.version = 4.0.0
> +jna.version = 4.3.0
> Causes these compilation errors in 
> geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:906:
>  error: TcpKeepAlive is not abstract and does not override abstract method 
> getFieldOrder() in Structure
> public static final class TcpKeepAlive extends Structure {
> ^
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:912:
>  error: getFieldOrder() in TcpKeepAlive cannot override getFieldOrder() in 
> Structure
>   protected List getFieldOrder() {
> ^
>   return type List is not compatible with List
> /Users/klund/dev/gemfire/open/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:911:
>  error: method does not override or implement a method from a supertype
>   @Override
>   ^
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2539:
--

New version 9.4.2.v20170220 is now out. We should upgrade to this one now.

9.3.6.v20151106 (Nov, 2015) <-- current version
9.4.0.v20161208 (Dec, 2016)
9.4.2.v20170220 (Feb, 2017)

> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> ... 4 more
> 38 tests completed, 

[jira] [Created] (GEODE-2557) Upgrade jna dependency

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2557:


 Summary: Upgrade jna dependency
 Key: GEODE-2557
 URL: https://issues.apache.org/jira/browse/GEODE-2557
 Project: Geode
  Issue Type: Wish
  Components: build, general
Reporter: Kirk Lund


Upgrade our jna dependency from 4.0.0 to 4.3.0. Dependency name is:

net.java.dev.jna:jna:4.3.0

Upgrading this dependency in gradle/dependency-versions.properties:

-jna.version = 4.0.0
+jna.version = 4.3.0

Causes these compilation errors in 
geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:
{noformat}
/Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:906:
 error: TcpKeepAlive is not abstract and does not override abstract method 
getFieldOrder() in Structure
public static final class TcpKeepAlive extends Structure {
^
/Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:912:
 error: getFieldOrder() in TcpKeepAlive cannot override getFieldOrder() in 
Structure
  protected List getFieldOrder() {
^
  return type List is not compatible with List
/Users/klund/dev/gemfire/open/geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java:911:
 error: method does not override or implement a method from a supertype
  @Override
  ^
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2461) Remove unnecessary explicit dependencies

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2461:


Commit b5cbaed14ae11101f99fd9ff79c90c67fdcd737f in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b5cbaed ]

GEODE-2461: remove json4s-ast_2.10 as explicit dependency


> Remove unnecessary explicit dependencies
> 
>
> Key: GEODE-2461
> URL: https://issues.apache.org/jira/browse/GEODE-2461
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> These unused entries are potential candidates for removal from 
> gradle/dependency-versions.properties:
> * cdi-api.version
> * hadoop.version*
> * hbase.version (remove contains check from geode-assembly)
> * hibernate.version
> * hibernate-commons-annotations.version
> * hsqldb.version
> * jline.version
> * jsr305.version
> * paranamer.version
> * quartz.version
> * spymemcached.version? (remove testCompile from geode-core)
> These entries are actually for transitive dependencies and should have the 
> explicit dependency removed:
> * activation.version
> * asm.version (done)
> * cglib.version (remove testRuntime from test.gradle)
> * classmate (remove compile from geode-web-api)
> * mortbay-jetty-servlet-api.version? (remove provided from geode-pulse)
> * scala.version (remove compile from geode-web-api)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2526) Enhance log statement in StatsArchiveReader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2526:


Commit fb1fdf90198e4767114e32c53c9fc61ceb4c4645 in geode's branch 
refs/heads/GEODE-4160-mockito from [~Srikanth Manvi]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb1fdf9 ]

GEODE-2526: Enhance log statement to include ResourceTypeName

This closes #406


> Enhance log statement in StatsArchiveReader
> ---
>
> Key: GEODE-2526
> URL: https://issues.apache.org/jira/browse/GEODE-2526
> Project: Geode
>  Issue Type: New Feature
>  Components: statistics
>Reporter: Srikanth Manvi
>Assignee: Srikanth Manvi
>Priority: Trivial
> Fix For: 1.2.0
>
>
> Rarely stats files are corrupted due to missing ResourceType info in the gfs 
> file. In those cases the gfs files cannot be opened in VSD tool as the tool 
> throws an error while loading.
> The log statement in the method 
> StatsArchiveReader.java(readResourceInstanceCreateToken())  prints out only 
> the missing ResourceTypeId which appears to be dynamically created. 
> If the log message can be enhanced to include the resourceName as well, it 
> will be valuable to know the name of ResourceType that is actually missing in 
> the stats file. 
> There is a [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility which takes in a corrupted stats files, name and id of the missing 
> ResourceType in the corrupted file and outputs a new .gfs file by filling in 
> the missing resource info. The new file can then be loaded and analyzed in 
> VSD.
>  
> For the [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility to be usable one needs to know the actual name of missing 
> resourceType, hence this New feature request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2547) Interest registration can cause a CacheLoader to be invoked

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2547:


Commit 1a36d36ec90d91094689cc3cb30c21be9b25276b in geode's branch 
refs/heads/GEODE-4160-mockito from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1a36d36 ]

GEODE-2547: Interest registration no longer causes a CacheLoader to be invoked


> Interest registration can cause a CacheLoader to be invoked
> ---
>
> Key: GEODE-2547
> URL: https://issues.apache.org/jira/browse/GEODE-2547
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> A simple scenario to reproduce this issue is:
> - configure a Region with a CacheLoader
> - destroy a key (it doesn't matter if the entry exists)
> - register interest in that key
> The CacheLoader will be invoked



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2556) RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2556:
-
Component/s: regions

> RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] 
> fails intermittently
> --
>
> Key: GEODE-2556
> URL: https://issues.apache.org/jira/browse/GEODE-2556
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Kirk Lund
>  Labels: Flaky
>
> I've seen this fail off and on in precheckin, but it always passes when I run 
> it by itself.
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
> testRollServersOnPersistentRegion_dataserializable[0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
> in VM 1 running on Host d8f0ab20fb04 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)
> Caused by:
> java.lang.Error: Entry for key:25 does not exist
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2556) RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2556:
-
Labels: Flaky  (was: )

> RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] 
> fails intermittently
> --
>
> Key: GEODE-2556
> URL: https://issues.apache.org/jira/browse/GEODE-2556
> Project: Geode
>  Issue Type: Bug
>Reporter: Kirk Lund
>  Labels: Flaky
>
> I've seen this fail off and on in precheckin, but it always passes when I run 
> it by itself.
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
> testRollServersOnPersistentRegion_dataserializable[0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
> in VM 1 running on Host d8f0ab20fb04 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)
> Caused by:
> java.lang.Error: Entry for key:25 does not exist
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2556) RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] fails intermittently

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2556:
-
Description: 
I've seen this fail off and on in precheckin, but it always passes when I run 
it by itself.
{noformat}
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
testRollServersOnPersistentRegion_dataserializable[0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
in VM 1 running on Host d8f0ab20fb04 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)

Caused by:
java.lang.Error: Entry for key:25 does not exist
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
{noformat}

  was:
{noformat}
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
testRollServersOnPersistentRegion_dataserializable[0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
in VM 1 running on Host d8f0ab20fb04 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)

Caused by:
java.lang.Error: Entry for key:25 does not exist
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
{noformat}


> RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] 
> fails intermittently
> --
>
> Key: GEODE-2556
> URL: https://issues.apache.org/jira/browse/GEODE-2556
> Project: Geode
>  Issue Type: Bug
>Reporter: Kirk Lund
>
> I've seen this fail off and on in precheckin, but it always passes when I run 
> it by itself.
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
> testRollServersOnPersistentRegion_dataserializable[0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
> in VM 1 running on Host d8f0ab20fb04 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)
> Caused by:
> java.lang.Error: Entry for key:25 does not exist
> at 
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2556) RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] fails intermittently

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2556:


 Summary: 
RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable[0] 
fails intermittently
 Key: GEODE-2556
 URL: https://issues.apache.org/jira/browse/GEODE-2556
 Project: Geode
  Issue Type: Bug
Reporter: Kirk Lund


{noformat}
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest > 
testRollServersOnPersistentRegion_dataserializable[0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$12.run 
in VM 1 running on Host d8f0ab20fb04 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putDataSerializableAndVerify(RollingUpgradeDUnitTest.java:294)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.putAndVerify(RollingUpgradeDUnitTest.java:246)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206)
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.testRollServersOnPersistentRegion_dataserializable(RollingUpgradeDUnitTest.java:134)

Caused by:
java.lang.Error: Entry for key:25 does not exist
at 
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.assertEntryExists(RollingUpgradeDUnitTest.java:797)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: export logs and stats

[Dan Smith]

I think maybe I didn't quite understand the original proposal. Are you
saying you won't even look at the directory or filename the user specifies,
but just grab all the files that happen to be in the working directory and
end in .log? I don't think that's going to do the right thing for most
users.

Very commonly users do direct their logs to separate directory, at least a
subdirectory of their working directory. And they often put all of their
logs into that directory - application logs, gemfire logs, etc. So I think
you really do need to look at the directory and filename they are
specifying.

Now, if you are just saying that their filename has to end in .log, that
seems like a reasonable restriction. It seems like maybe we already have
that restriction if you're hitting an IndexOutOfBoundError.

-Dan

On Tue, Feb 28, 2017 at 4:20 PM, Jinmei Liao  wrote:

> Darrel, it seems if user defines a log file to be simply "serverLog" (a
> filename with no "."), when rolling over the log file once file size is
> reached, we get a IndexOutOfBoundError when it's trying to figure out
> what's the rolled-over filename should be.
>
> And if user defines a log file name to be "server.log.gz", when rolling
> over, the new filename seems to be "server.log_01_01.gz". Does not look
> like we handle the ".gz' suffix correctly. For now, we do want to enforce
> the log/stats filename ends with appropriate suffix.
>
> On Tue, Feb 28, 2017 at 3:16 PM, Darrel Schneider 
> wrote:
>
> > It sounds like you will pick up any file in the working directory that
> ends
> > with ".log" or ".log.gz".
> > But what if the geode server is sharing a directory with something else
> > that is also writing files with these extensions?
> > Or if multiple geode servers are running in the same directory?
> > I think it would be better to use the configured log file name and stat
> > archive name and use that to find the logs and stats to gather. The
> rolling
> > code has already been written that will find all the existing logs and
> > stats. In any bugs in that code need to be fixed since it would break the
> > code that removes old files based on disk space. So it seems like you
> > should be able to use this same code to get a list of the files to copy.
> >
> >
> > On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith  wrote:
> >
> > > I'm a bit confused by (1). Isn't it actually more complicated for you
> to
> > > restrict log collection to a relative path? Why not just look for log
> > files
> > > no matter where they are written to? I also don't really follow the
> > > argument about why a user that writes to /var/logs is not going to want
> > to
> > > use this command. Won't all users want to be able to gather their logs
> > > using this command?
> > >
> > > 2 seems reasonable. It seems like we should restrict the file names if
> we
> > > are going to have this limitation.
> > >
> > > -Dan
> > >
> > > On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao 
> wrote:
> > >
> > > > Hello community,
> > > >
> > > > We are currently trying to improve what "export logs" should do.
> > > Currently
> > > > export logs only export the logs(filtered by logLevel and start and
> end
> > > > date) to each individual member's file system. We want to make all
> the
> > > > member's logs exported to a central location  and if you are
> connecting
> > > > using http, it will be exported to your local file system. This is to
> > > > facilitate gathering logs in the cloud environment.
> > > >
> > > > That said, for the first round of implementation, we would like to
> > impose
> > > > these restrictions to this command:
> > > > 1) it will only look for the logs/stats in each members working
> > directory
> > > > only.
> > > > 2) it will only look for files that ends with .log, .log.gz, .gfs or
> > > > .gfs.gz.
> > > >
> > > > Background for 1): if you started your locator/server with "log-file"
> > or
> > > > "statistics-archive-file" with an absolute path, it will write these
> > > files
> > > > to that location, but if you simply give it a relative path, the
> files
> > > will
> > > > be written to the member's working directory. The reasoning behind 1)
> > is
> > > > that this command is mostly for those environment that you can't
> easily
> > > go
> > > > to the member's filesystem to get logs, but if you have started your
> > > > server/locator with an absolute path like "/var/logs", we are
> assuming
> > > you
> > > > already know how to get the logs, thus this command to not mean much
> to
> > > > you.
> > > >
> > > > For restriction 2), since logs and stats files roll over, it is much
> > > easier
> > > > to find the target files with extensions rather than file name
> > patterns.
> > > We
> > > > could either do not allow you to start server/locator with other file
> > > name
> > > > suffix or post a warning. We would need the community's input on
> this.
> > > >
> > > > Any feedback is 

Re: export logs and stats

[Jinmei Liao]

Darrel, it seems if user defines a log file to be simply "serverLog" (a
filename with no "."), when rolling over the log file once file size is
reached, we get a IndexOutOfBoundError when it's trying to figure out
what's the rolled-over filename should be.

And if user defines a log file name to be "server.log.gz", when rolling
over, the new filename seems to be "server.log_01_01.gz". Does not look
like we handle the ".gz' suffix correctly. For now, we do want to enforce
the log/stats filename ends with appropriate suffix.

On Tue, Feb 28, 2017 at 3:16 PM, Darrel Schneider 
wrote:

> It sounds like you will pick up any file in the working directory that ends
> with ".log" or ".log.gz".
> But what if the geode server is sharing a directory with something else
> that is also writing files with these extensions?
> Or if multiple geode servers are running in the same directory?
> I think it would be better to use the configured log file name and stat
> archive name and use that to find the logs and stats to gather. The rolling
> code has already been written that will find all the existing logs and
> stats. In any bugs in that code need to be fixed since it would break the
> code that removes old files based on disk space. So it seems like you
> should be able to use this same code to get a list of the files to copy.
>
>
> On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith  wrote:
>
> > I'm a bit confused by (1). Isn't it actually more complicated for you to
> > restrict log collection to a relative path? Why not just look for log
> files
> > no matter where they are written to? I also don't really follow the
> > argument about why a user that writes to /var/logs is not going to want
> to
> > use this command. Won't all users want to be able to gather their logs
> > using this command?
> >
> > 2 seems reasonable. It seems like we should restrict the file names if we
> > are going to have this limitation.
> >
> > -Dan
> >
> > On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao  wrote:
> >
> > > Hello community,
> > >
> > > We are currently trying to improve what "export logs" should do.
> > Currently
> > > export logs only export the logs(filtered by logLevel and start and end
> > > date) to each individual member's file system. We want to make all the
> > > member's logs exported to a central location  and if you are connecting
> > > using http, it will be exported to your local file system. This is to
> > > facilitate gathering logs in the cloud environment.
> > >
> > > That said, for the first round of implementation, we would like to
> impose
> > > these restrictions to this command:
> > > 1) it will only look for the logs/stats in each members working
> directory
> > > only.
> > > 2) it will only look for files that ends with .log, .log.gz, .gfs or
> > > .gfs.gz.
> > >
> > > Background for 1): if you started your locator/server with "log-file"
> or
> > > "statistics-archive-file" with an absolute path, it will write these
> > files
> > > to that location, but if you simply give it a relative path, the files
> > will
> > > be written to the member's working directory. The reasoning behind 1)
> is
> > > that this command is mostly for those environment that you can't easily
> > go
> > > to the member's filesystem to get logs, but if you have started your
> > > server/locator with an absolute path like "/var/logs", we are assuming
> > you
> > > already know how to get the logs, thus this command to not mean much to
> > > you.
> > >
> > > For restriction 2), since logs and stats files roll over, it is much
> > easier
> > > to find the target files with extensions rather than file name
> patterns.
> > We
> > > could either do not allow you to start server/locator with other file
> > name
> > > suffix or post a warning. We would need the community's input on this.
> > >
> > > Any feedback is appreciated.
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>



-- 
Cheers

Jinmei

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2142:


Commit abeaa244b5c814f6040176d34551061c4b3b3b25 in geode's branch 
refs/heads/GEODE-4160-mockito from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=abeaa24 ]

GEODE-2142: removing tests so run precheckin


> 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
>Assignee: Udo Kohlmeyer
>Priority: Blocker
>  Labels: json
> Fix For: 1.2.0
>
>
> 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.15#6346)

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2142:


Commit f2262d13a81c59918f06a78c1073c76062e7f238 in geode's branch 
refs/heads/GEODE-4160-mockito from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f2262d1 ]

GEODE-2142: Removing JSON licence stuff from NOTICE files


> 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
>Assignee: Udo Kohlmeyer
>Priority: Blocker
>  Labels: json
> Fix For: 1.2.0
>
>
> 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.15#6346)

[jira] [Commented] (GEODE-2515) CI Failure: BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED failed with AssertionFailedError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2515:


Commit 8ff2fd4017ade81510e7705bf0f3254154a8805d in geode's branch 
refs/heads/GEODE-4160-mockito from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8ff2fd4 ]

GEODE-2515: Disabling BaseLineAndCompareQueryPerfJUnitTest

This is a performance test, it should not be run as part of precheckin.


> CI Failure: 
> BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries FAILED 
> failed with AssertionFailedError
> ---
>
> Key: GEODE-2515
> URL: https://issues.apache.org/jira/browse/GEODE-2515
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
>   java.lang.AssertionError: Avg. Time taken to query with index should be 
> less than time taken without index
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.cache.query.BaseLineAndCompareQueryPerfJUnitTest.testPerformanceForRangeQueries(BaseLineAndCompareQueryPerfJUnitTest.java:299)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2545) NPE during lucene query execution when cache is closing or region is destroyed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2545:


Commit c4a5ab284baba371418cb7a389cb0f327d8becdc in geode's branch 
refs/heads/GEODE-4160-mockito from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c4a5ab2 ]

GEODE-2545: NPE during lucene query execution when cache is closing or region 
is destroyed

* Throw an InternalFunctionTargetInvocationException if executing a query while 
cache is closing


> NPE during lucene query execution when cache is closing or region is destroyed
> --
>
> Key: GEODE-2545
> URL: https://issues.apache.org/jira/browse/GEODE-2545
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> If the LuceneQueryFunction executes while a cache is closing, it is possible 
> that the function receives a null region/index.  In this case the NPE is 
> thrown.  Instead we should detect this and fail the function.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2538) Lucene query with values should not invoke cache loader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2538:


Commit 712d87f791906cbd1c11dd0f4655032dabf57755 in geode's branch 
refs/heads/GEODE-4160-mockito from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=712d87f ]

GEODE-2538: Don't invoke a cache loader when fetching values for a lucene query

Instead of using getAll, fetch the values of a lucene query using a
function that calls getEntry. We can then avoid invoking the cache
loader.


> Lucene query with values should not invoke cache loader
> ---
>
> Key: GEODE-2538
> URL: https://issues.apache.org/jira/browse/GEODE-2538
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> Lucene queries use getAll to fetch pages when returning values.
> If an entry is destroyed after the query has found the list of keys, but 
> before the query finds the values, the getAll with trigger a cache loader and 
> reload the value. This may be unexpected behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2550) Improve README

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2550:


Commit b5fd6b50b18ce13cb53ef72f9fe5f363cb566ba5 in geode's branch 
refs/heads/GEODE-4160-mockito from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b5fd6b5 ]

GEODE-2550 Improve README and BUILDING

This closes #407


> Improve README
> --
>
> Key: GEODE-2550
> URL: https://issues.apache.org/jira/browse/GEODE-2550
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Fix For: 1.2.0
>
>
> The project README and BUILDING could use some updates, particularly the 
> 'Geode in 5 minutes' example.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1995) remove ReliableMessageQueueFactory, ReliableMessageQueue, and getReliableMessageQueueFactory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1995:


Commit 5ec0d470f25ec4cb68dd7c5c31791eecb90b2548 in geode's branch 
refs/heads/GEODE-4160-mockito from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5ec0d47 ]

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory, 
ReliableMessageQueueFactoryImpl and
it's usage in the code from GemfireCacheImpl and DistributedRegion.

GEODE-1995: Addressing Review Comments.
  Removed ReliableDistributionData
  CacheOperationMessage does not required now to implement 
ReliableDistributionData, as it is removed
  Removed all reference of getOperations and getOperationCount
  AbstractRegion#handleReliableDistribution does not use 
ReliableDistributionData removed the same.
  Removed SendQueueOperation
  Removed sendQueue from DistributedRegion
  Cleanup LocalizedStrings
  Removed SEND_QUEUE_MESSAGE from DataSerializableFixedID and DSFIDFactory


> remove ReliableMessageQueueFactory, ReliableMessageQueue, and 
> getReliableMessageQueueFactory
> 
>
> Key: GEODE-1995
> URL: https://issues.apache.org/jira/browse/GEODE-1995
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>
> ReliableMessageQueueFactory, ReliableMessageQueue, and 
> GemFireCacheImpl.getReliableMessageQueueFactory should all be removed. They 
> are internal and were never used. No tests exist for them.
> They are part of required Roles which is a deprecated feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1995) remove ReliableMessageQueueFactory, ReliableMessageQueue, and getReliableMessageQueueFactory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1995:


Commit 5ec0d470f25ec4cb68dd7c5c31791eecb90b2548 in geode's branch 
refs/heads/GEODE-4160-mockito from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5ec0d47 ]

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory, 
ReliableMessageQueueFactoryImpl and
it's usage in the code from GemfireCacheImpl and DistributedRegion.

GEODE-1995: Addressing Review Comments.
  Removed ReliableDistributionData
  CacheOperationMessage does not required now to implement 
ReliableDistributionData, as it is removed
  Removed all reference of getOperations and getOperationCount
  AbstractRegion#handleReliableDistribution does not use 
ReliableDistributionData removed the same.
  Removed SendQueueOperation
  Removed sendQueue from DistributedRegion
  Cleanup LocalizedStrings
  Removed SEND_QUEUE_MESSAGE from DataSerializableFixedID and DSFIDFactory


> remove ReliableMessageQueueFactory, ReliableMessageQueue, and 
> getReliableMessageQueueFactory
> 
>
> Key: GEODE-1995
> URL: https://issues.apache.org/jira/browse/GEODE-1995
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>
> ReliableMessageQueueFactory, ReliableMessageQueue, and 
> GemFireCacheImpl.getReliableMessageQueueFactory should all be removed. They 
> are internal and were never used. No tests exist for them.
> They are part of required Roles which is a deprecated feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2460) Update dependency versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2460:


Commit bc32a76c223d7a2b407fed72595af4056a78e433 in geode's branch 
refs/heads/GEODE-4160-mockito from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc32a76 ]

GEODE-2460: update dependency versions

* com.fasterxml.jackson.core:jackson-annotation:2.8.6
* com.fasterxml.jackson.core:jackson-core:2.8.6
* com.fasterxml.jackson.core:jackson-databind:2.8.6
* com.fasterxml.jackson.module:jackson-module-scala_2.10:2.8.6
* org.eclipse.persistence:javax.persistence:2.1.1
* fix dependency versions in NOTICE files


> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2404) Add API to destroy a region containing lucene indexes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2404:


Commit 11521a824f31ff03db13d0e59cb0fbf29e592151 in geode's branch 
refs/heads/GEODE-4160-mockito from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=11521a8 ]

GEODE-2404: Added support for destroying lucene indexes


> Add API to destroy a region containing lucene indexes
> -
>
> Key: GEODE-2404
> URL: https://issues.apache.org/jira/browse/GEODE-2404
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: DestroyRegionMultipleMembersFunction.java
>
>
> h2. Description
> An application {{Region}} containing {{LuceneIndexes}} should be able to be 
> destroyed.
> There are several options, including:
> - Invoke one API to destroy both the application {{Region}} and its 
> {{LuceneIndexes}}
> - Invoke two API:
> ## destroy the {{LuceneIndexes}}
> ## destroy application {{Region}} as it is done currently
> h3. One API
> In this case, we would need a callback on {{LuceneService}} to destroy the 
> {{LuceneIndexes}} before destroying the application {{Region}} like:
> {noformat}
> public void beforeDestroyRegion(Region region);
> {noformat}
> This API would get all the {{LuceneIndexes}} for the application {{Region}}, 
> then destroy each one. See the *Two API* section below for details on 
> destroying a {{LuceneIndex}}.
> Without changes to the way {{PartitionedRegions}} are destroyed, this causes 
> an issue though.
> The current behavior of {{PartitionedRegion destroyRegion}} is to first check 
> for colocated children. If there are any, the call fails.
> There are two options for adding the call to destroy the {{LuceneIndexes}}:
> # check for colocated children
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # do the rest of the destroy
> 
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # check for colocated children
> # do the rest of the destroy
> Both of these options are problematic in different ways.
> In the case of a {{PartitionedRegion}} with {{LuceneIndexes}}, there are 
> colocated children, so the first option would cause the {{destroyRegion}} 
> call to fail; the second option would succeed. I don't think the first option 
> should fail since the colocated children are internal {{Regions}} that the 
> application knows nothing about.
> In the case of a {{PartitionedRegion}} defining {{LuceneIndexes}} and having 
> an {{AsyncEventQueue}}, there are colocated children, so the first option 
> would cause the {{destroyRegion}} call to fail. This is ok since one of the 
> children is an application-known {{AsyncEventQueue}}. The second option would 
> fail in a bad way. It would first remove the {{LuceneIndexes}}, then fail the 
> colocated children check, so the {{destroyRegion}} call would fail. In this 
> case, the application {{Region}} doesn't get destroyed but its 
> {{LuceneIndexes}} do. This would be bad.
> One option would be to look into changing the check for colocated children to 
> check for application-defined (or not hidden) colocated children. Then the 
> code would be something like:
> # check for application-defined colocated children
> # invoke LuceneService beforeDestroyRegion to remove the LuceneIndexes
> # do the rest of the destroy
> I think this would be ok in both cases.
> h3. Two API
> The destroy API on {{LuceneIndex}} would be something like:
> {noformat}
> public void destroy();
> {noformat}
> Destroying each {{LuceneIndex}} would require:
> # destroying the chunk {{Region}}
> # destroying the file {{Region}}
> # destroying the {{AsyncEventQueue}} which would require:
> ## retrieving and stopping the {{AsyncEventQueue's}} underlying 
> {{GatewaySender}} (there probably should be stop API on {{AsyncEventQueue}} 
> which does this)
> ## removing the id from the application {{Region's AsyncEventQueue}} ids
> ## destroying the {{AsyncEventQueue}} (this destroys the underlying 
> {{GatewaySender}} and removes it from the {{GemFireCacheImpl's}} collection 
> of {{GatewaySenders}})
> ## removing the {{AsyncEventQueue}} from the {{GemFireCacheImpl's}} 
> collection of {{AsyncEventQueues}} (this should be included in the destroy 
> method above)
> # removing {{LuceneIndex}} from {{LuceneService's}} map of indexes
> I also think the API on {{LuceneService}} should be something like:
> {noformat}
> public void destroyIndexes(String regionPath);
> public void destroyIndex(String indexName, String regionPath);
> {noformat}
> These methods would get the appropriate {{LuceneIndex(es)}} and invoke 
> destroy 

[jira] [Resolved] (GEODE-2547) Interest registration can cause a CacheLoader to be invoked

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2547.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Interest registration can cause a CacheLoader to be invoked
> ---
>
> Key: GEODE-2547
> URL: https://issues.apache.org/jira/browse/GEODE-2547
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> A simple scenario to reproduce this issue is:
> - configure a Region with a CacheLoader
> - destroy a key (it doesn't matter if the entry exists)
> - register interest in that key
> The CacheLoader will be invoked



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2547) Interest registration can cause a CacheLoader to be invoked

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2547:


Commit 1a36d36ec90d91094689cc3cb30c21be9b25276b in geode's branch 
refs/heads/develop from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1a36d36 ]

GEODE-2547: Interest registration no longer causes a CacheLoader to be invoked


> Interest registration can cause a CacheLoader to be invoked
> ---
>
> Key: GEODE-2547
> URL: https://issues.apache.org/jira/browse/GEODE-2547
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> A simple scenario to reproduce this issue is:
> - configure a Region with a CacheLoader
> - destroy a key (it doesn't matter if the entry exists)
> - register interest in that key
> The CacheLoader will be invoked



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2325) Improve tests for JarDeployer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2325:


Commit 228bf4ff7ff45e44f2f1062f05a8b71b9616761c in geode's branch 
refs/heads/GEODE-2290 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=228bf4f ]

GEODE-2325: Improve tests for JarDeployer

WIP


> Improve tests for JarDeployer
> -
>
> Key: GEODE-2325
> URL: https://issues.apache.org/jira/browse/GEODE-2325
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> org.apache.geode.internal.JarDeployer only has a DUnit test right now.  Many 
> of those test methods are really just unit tests, and should be extracted to 
> run as such.  The tests can also be cleaned up a lot with AssertJ.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2526) Enhance log statement in StatsArchiveReader

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2526.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Enhance log statement in StatsArchiveReader
> ---
>
> Key: GEODE-2526
> URL: https://issues.apache.org/jira/browse/GEODE-2526
> Project: Geode
>  Issue Type: New Feature
>  Components: statistics
>Reporter: Srikanth Manvi
>Assignee: Srikanth Manvi
>Priority: Trivial
> Fix For: 1.2.0
>
>
> Rarely stats files are corrupted due to missing ResourceType info in the gfs 
> file. In those cases the gfs files cannot be opened in VSD tool as the tool 
> throws an error while loading.
> The log statement in the method 
> StatsArchiveReader.java(readResourceInstanceCreateToken())  prints out only 
> the missing ResourceTypeId which appears to be dynamically created. 
> If the log message can be enhanced to include the resourceName as well, it 
> will be valuable to know the name of ResourceType that is actually missing in 
> the stats file. 
> There is a [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility which takes in a corrupted stats files, name and id of the missing 
> ResourceType in the corrupted file and outputs a new .gfs file by filling in 
> the missing resource info. The new file can then be loaded and analyzed in 
> VSD.
>  
> For the [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility to be usable one needs to know the actual name of missing 
> resourceType, hence this New feature request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-880) Remove unused classes

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-880.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove unused classes
> -
>
> Key: GEODE-880
> URL: https://issues.apache.org/jira/browse/GEODE-880
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Reporter: Kirk Lund
> Fix For: 1.2.0
>
>
> We would typically only keep unused classes if they were part of the user API 
> in a previous release.
> If an unused class is not required for backwards compatibility then it should 
> be deleted. This jira ticket lists unused classes that should be removed. If 
> you delete any of these classes, please add an appropriate comment and then 
> remove the class name from the ticket description.
> * geode-core/src/test/java/com/gemstone/gemfire/internal/JavaExec.java
> * geode-core/src/test/java/com/gemstone/gemfire/internal/LongBuffer.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2526) Enhance log statement in StatsArchiveReader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2526:


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

GEODE-2526: Enhance log statement to include ResourceTypeName

This closes #406


> Enhance log statement in StatsArchiveReader
> ---
>
> Key: GEODE-2526
> URL: https://issues.apache.org/jira/browse/GEODE-2526
> Project: Geode
>  Issue Type: New Feature
>  Components: statistics
>Reporter: Srikanth Manvi
>Assignee: Srikanth Manvi
>Priority: Trivial
>
> Rarely stats files are corrupted due to missing ResourceType info in the gfs 
> file. In those cases the gfs files cannot be opened in VSD tool as the tool 
> throws an error while loading.
> The log statement in the method 
> StatsArchiveReader.java(readResourceInstanceCreateToken())  prints out only 
> the missing ResourceTypeId which appears to be dynamically created. 
> If the log message can be enhanced to include the resourceName as well, it 
> will be valuable to know the name of ResourceType that is actually missing in 
> the stats file. 
> There is a [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility which takes in a corrupted stats files, name and id of the missing 
> ResourceType in the corrupted file and outputs a new .gfs file by filling in 
> the missing resource info. The new file can then be loaded and analyzed in 
> VSD.
>  
> For the [stats-cleaner | https://github.com/smanvi-pivotal/stats-cleaner] 
> utility to be usable one needs to know the actual name of missing 
> resourceType, hence this New feature request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: export logs and stats

[Jinmei Liao]

Darrel, great, can you point me to the code to get a list of the files to
copy?

On Tue, Feb 28, 2017 at 3:16 PM, Darrel Schneider 
wrote:

> It sounds like you will pick up any file in the working directory that ends
> with ".log" or ".log.gz".
> But what if the geode server is sharing a directory with something else
> that is also writing files with these extensions?
> Or if multiple geode servers are running in the same directory?
> I think it would be better to use the configured log file name and stat
> archive name and use that to find the logs and stats to gather. The rolling
> code has already been written that will find all the existing logs and
> stats. In any bugs in that code need to be fixed since it would break the
> code that removes old files based on disk space. So it seems like you
> should be able to use this same code to get a list of the files to copy.
>
>
> On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith  wrote:
>
> > I'm a bit confused by (1). Isn't it actually more complicated for you to
> > restrict log collection to a relative path? Why not just look for log
> files
> > no matter where they are written to? I also don't really follow the
> > argument about why a user that writes to /var/logs is not going to want
> to
> > use this command. Won't all users want to be able to gather their logs
> > using this command?
> >
> > 2 seems reasonable. It seems like we should restrict the file names if we
> > are going to have this limitation.
> >
> > -Dan
> >
> > On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao  wrote:
> >
> > > Hello community,
> > >
> > > We are currently trying to improve what "export logs" should do.
> > Currently
> > > export logs only export the logs(filtered by logLevel and start and end
> > > date) to each individual member's file system. We want to make all the
> > > member's logs exported to a central location  and if you are connecting
> > > using http, it will be exported to your local file system. This is to
> > > facilitate gathering logs in the cloud environment.
> > >
> > > That said, for the first round of implementation, we would like to
> impose
> > > these restrictions to this command:
> > > 1) it will only look for the logs/stats in each members working
> directory
> > > only.
> > > 2) it will only look for files that ends with .log, .log.gz, .gfs or
> > > .gfs.gz.
> > >
> > > Background for 1): if you started your locator/server with "log-file"
> or
> > > "statistics-archive-file" with an absolute path, it will write these
> > files
> > > to that location, but if you simply give it a relative path, the files
> > will
> > > be written to the member's working directory. The reasoning behind 1)
> is
> > > that this command is mostly for those environment that you can't easily
> > go
> > > to the member's filesystem to get logs, but if you have started your
> > > server/locator with an absolute path like "/var/logs", we are assuming
> > you
> > > already know how to get the logs, thus this command to not mean much to
> > > you.
> > >
> > > For restriction 2), since logs and stats files roll over, it is much
> > easier
> > > to find the target files with extensions rather than file name
> patterns.
> > We
> > > could either do not allow you to start server/locator with other file
> > name
> > > suffix or post a warning. We would need the community's input on this.
> > >
> > > Any feedback is appreciated.
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>



-- 
Cheers

Jinmei

Re: apache-geode/lib/ra.jar

[Mark Bretl]

Hi Kirk,

ra.jar gets built from geode-core, here is the build task:

task raJar (type: Jar, dependsOn: classes) {
  description 'Assembles the jar archive that contains the JCA classes'
  from sourceSets.jca.output
  exclude 'org/apache/geode/ra/**'
  archiveName 'ra.jar'
}

I see no reason why it shouldn't have a 'geode' prefix, probably an oversight.

--Mark


On Tue, Feb 28, 2017 at 3:11 PM, Kirk Lund  wrote:

> Does anyone know why "apache-geode/lib/ra.jar" doesn't have a geode- prefix
> and release numbers in the jar name? This is the only unidentified jar in
> the Apache Geode lib directory, and I think we should change this to be
> named like the other jars if possible. It seems to contain JCA classes from
> geode-core.
>
> /Users/klund/dev/geode/geode-
> assembly/build/install/apache-geode/lib [512]$ jar -tvf ra.jar
>  0 Tue Feb 28 14:22:20 PST 2017 META-INF/
>131 Tue Feb 28 14:22:20 PST 2017 META-INF/MANIFEST.MF
>  21685 Mon Feb 27 15:55:04 PST 2017 META-INF/LICENSE
>574 Mon Feb 27 15:55:04 PST 2017 META-INF/NOTICE
>  0 Tue Feb 28 14:19:26 PST 2017 org/
>  0 Tue Feb 28 14:19:26 PST 2017 org/apache/
>  0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/
>  0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/
>  0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
>   1688 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
> GFConnectionFactoryImpl.class
>   1343 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
> GFConnectionImpl.class
>  0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
>   4940 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
> spi/JCALocalTransaction.class
>   7795 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
> spi/JCAManagedConnection.class
>   3451 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
> JCAManagedConnectionFactory.class
>   1089 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
> JCAManagedConnectionMetaData.class
>

Re: export logs and stats

[Darrel Schneider]

It sounds like you will pick up any file in the working directory that ends
with ".log" or ".log.gz".
But what if the geode server is sharing a directory with something else
that is also writing files with these extensions?
Or if multiple geode servers are running in the same directory?
I think it would be better to use the configured log file name and stat
archive name and use that to find the logs and stats to gather. The rolling
code has already been written that will find all the existing logs and
stats. In any bugs in that code need to be fixed since it would break the
code that removes old files based on disk space. So it seems like you
should be able to use this same code to get a list of the files to copy.


On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith  wrote:

> I'm a bit confused by (1). Isn't it actually more complicated for you to
> restrict log collection to a relative path? Why not just look for log files
> no matter where they are written to? I also don't really follow the
> argument about why a user that writes to /var/logs is not going to want to
> use this command. Won't all users want to be able to gather their logs
> using this command?
>
> 2 seems reasonable. It seems like we should restrict the file names if we
> are going to have this limitation.
>
> -Dan
>
> On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao  wrote:
>
> > Hello community,
> >
> > We are currently trying to improve what "export logs" should do.
> Currently
> > export logs only export the logs(filtered by logLevel and start and end
> > date) to each individual member's file system. We want to make all the
> > member's logs exported to a central location  and if you are connecting
> > using http, it will be exported to your local file system. This is to
> > facilitate gathering logs in the cloud environment.
> >
> > That said, for the first round of implementation, we would like to impose
> > these restrictions to this command:
> > 1) it will only look for the logs/stats in each members working directory
> > only.
> > 2) it will only look for files that ends with .log, .log.gz, .gfs or
> > .gfs.gz.
> >
> > Background for 1): if you started your locator/server with "log-file" or
> > "statistics-archive-file" with an absolute path, it will write these
> files
> > to that location, but if you simply give it a relative path, the files
> will
> > be written to the member's working directory. The reasoning behind 1) is
> > that this command is mostly for those environment that you can't easily
> go
> > to the member's filesystem to get logs, but if you have started your
> > server/locator with an absolute path like "/var/logs", we are assuming
> you
> > already know how to get the logs, thus this command to not mean much to
> > you.
> >
> > For restriction 2), since logs and stats files roll over, it is much
> easier
> > to find the target files with extensions rather than file name patterns.
> We
> > could either do not allow you to start server/locator with other file
> name
> > suffix or post a warning. We would need the community's input on this.
> >
> > Any feedback is appreciated.
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: export logs and stats

[Jinmei Liao]

I think restriction1) also has something to do with not needing to parse
the file path/names. If you define an absolute path, we will need to parse
the string to get the directory and file name. Besides, if all the logs are
already written to a centralized place, just zip them up and send it over,
you don't need this command. But the command does have the capability of
being able to filter the logs though. I do see your point.

On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith  wrote:

> I'm a bit confused by (1). Isn't it actually more complicated for you to
> restrict log collection to a relative path? Why not just look for log files
> no matter where they are written to? I also don't really follow the
> argument about why a user that writes to /var/logs is not going to want to
> use this command. Won't all users want to be able to gather their logs
> using this command?
>
> 2 seems reasonable. It seems like we should restrict the file names if we
> are going to have this limitation.
>
> -Dan
>
> On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao  wrote:
>
> > Hello community,
> >
> > We are currently trying to improve what "export logs" should do.
> Currently
> > export logs only export the logs(filtered by logLevel and start and end
> > date) to each individual member's file system. We want to make all the
> > member's logs exported to a central location  and if you are connecting
> > using http, it will be exported to your local file system. This is to
> > facilitate gathering logs in the cloud environment.
> >
> > That said, for the first round of implementation, we would like to impose
> > these restrictions to this command:
> > 1) it will only look for the logs/stats in each members working directory
> > only.
> > 2) it will only look for files that ends with .log, .log.gz, .gfs or
> > .gfs.gz.
> >
> > Background for 1): if you started your locator/server with "log-file" or
> > "statistics-archive-file" with an absolute path, it will write these
> files
> > to that location, but if you simply give it a relative path, the files
> will
> > be written to the member's working directory. The reasoning behind 1) is
> > that this command is mostly for those environment that you can't easily
> go
> > to the member's filesystem to get logs, but if you have started your
> > server/locator with an absolute path like "/var/logs", we are assuming
> you
> > already know how to get the logs, thus this command to not mean much to
> > you.
> >
> > For restriction 2), since logs and stats files roll over, it is much
> easier
> > to find the target files with extensions rather than file name patterns.
> We
> > could either do not allow you to start server/locator with other file
> name
> > suffix or post a warning. We would need the community's input on this.
> >
> > Any feedback is appreciated.
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

apache-geode/lib/ra.jar

[Kirk Lund]

Does anyone know why "apache-geode/lib/ra.jar" doesn't have a geode- prefix
and release numbers in the jar name? This is the only unidentified jar in
the Apache Geode lib directory, and I think we should change this to be
named like the other jars if possible. It seems to contain JCA classes from
geode-core.

/Users/klund/dev/geode/geode-
assembly/build/install/apache-geode/lib [512]$ jar -tvf ra.jar
 0 Tue Feb 28 14:22:20 PST 2017 META-INF/
   131 Tue Feb 28 14:22:20 PST 2017 META-INF/MANIFEST.MF
 21685 Mon Feb 27 15:55:04 PST 2017 META-INF/LICENSE
   574 Mon Feb 27 15:55:04 PST 2017 META-INF/NOTICE
 0 Tue Feb 28 14:19:26 PST 2017 org/
 0 Tue Feb 28 14:19:26 PST 2017 org/apache/
 0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/
 0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/
 0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
  1688 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
GFConnectionFactoryImpl.class
  1343 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
GFConnectionImpl.class
 0 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
  4940 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
spi/JCALocalTransaction.class
  7795 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/
spi/JCAManagedConnection.class
  3451 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
JCAManagedConnectionFactory.class
  1089 Tue Feb 28 14:19:26 PST 2017 org/apache/geode/internal/ra/spi/
JCAManagedConnectionMetaData.class

[jira] [Commented] (GEODE-880) Remove unused classes

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-880 Remove unused classes

This closes #409


> Remove unused classes
> -
>
> Key: GEODE-880
> URL: https://issues.apache.org/jira/browse/GEODE-880
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Reporter: Kirk Lund
>
> We would typically only keep unused classes if they were part of the user API 
> in a previous release.
> If an unused class is not required for backwards compatibility then it should 
> be deleted. This jira ticket lists unused classes that should be removed. If 
> you delete any of these classes, please add an appropriate comment and then 
> remove the class name from the ticket description.
> * geode-core/src/test/java/com/gemstone/gemfire/internal/JavaExec.java
> * geode-core/src/test/java/com/gemstone/gemfire/internal/LongBuffer.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Darrel Schneider]

> On Feb. 28, 2017, 2:21 p.m., Darrel Schneider wrote:
> > geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java,
> >  line 26
> > 
> >
> > I found it confusing PageEntry was DataSerializable. Usually we do not 
> > want our internal classes to use DataSerializable.
> > 
> > But it looks to me like this class is never serialized. Instead we 
> > directly call toData and fromData in the PageResults class.
> > 
> > So I think it would be better to make this a class that does not 
> > support serialization directly. Otherwise someone in the future may be 
> > tempted to pass an instance of this class to writeObject.
> > 
> > I could be wrong about this and it would be good to check with the 
> > serialization team to see what they think.
> 
> Dan Smith wrote:
> Sure - I just changed the class so it doesn't implement DataSerializable. 
> Let me know what you think.

Looks good!


- Darrel


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


On Feb. 28, 2017, 2:41 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57170/
> ---
> 
> (Updated Feb. 28, 2017, 2:41 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If values on the server are in serialized form, leave them that way and
> only deserialize the values on the clients.
> 
> This is implemented by having the LuceneGetPageFunction extract the
> serialized value and return the results in a new PageResults class,
> which handles the deserialization and upwrapping of the value if
> necessary.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java
>  4e45646cf8aba6a66ed77514d270ffadd74d9859 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
>  f5c2b99e5bcb58997e973bc660c11c3925711bd0 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
>  9264126b0bc6cdd63f702c5628346516e3979792 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
>  c62082cbd54be3719530d1f5ccb5dbb653c280e1 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/57170/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[GitHub] geode pull request #409: GEODE-880 Remove unused classes

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-880) Remove unused classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-880:
--

Github user asfgit closed the pull request at:

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


> Remove unused classes
> -
>
> Key: GEODE-880
> URL: https://issues.apache.org/jira/browse/GEODE-880
> Project: Geode
>  Issue Type: Wish
>  Components: general
>Reporter: Kirk Lund
>
> We would typically only keep unused classes if they were part of the user API 
> in a previous release.
> If an unused class is not required for backwards compatibility then it should 
> be deleted. This jira ticket lists unused classes that should be removed. If 
> you delete any of these classes, please add an appropriate comment and then 
> remove the class name from the ticket description.
> * geode-core/src/test/java/com/gemstone/gemfire/internal/JavaExec.java
> * geode-core/src/test/java/com/gemstone/gemfire/internal/LongBuffer.java



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On Feb. 28, 2017, 10:41 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57170/
> ---
> 
> (Updated Feb. 28, 2017, 10:41 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If values on the server are in serialized form, leave them that way and
> only deserialize the values on the clients.
> 
> This is implemented by having the LuceneGetPageFunction extract the
> serialized value and return the results in a new PageResults class,
> which handles the deserialization and upwrapping of the value if
> necessary.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java
>  4e45646cf8aba6a66ed77514d270ffadd74d9859 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
>  f5c2b99e5bcb58997e973bc660c11c3925711bd0 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
>  9264126b0bc6cdd63f702c5628346516e3979792 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
>  c62082cbd54be3719530d1f5ccb5dbb653c280e1 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/57170/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: export logs and stats

[Dan Smith]

I'm a bit confused by (1). Isn't it actually more complicated for you to
restrict log collection to a relative path? Why not just look for log files
no matter where they are written to? I also don't really follow the
argument about why a user that writes to /var/logs is not going to want to
use this command. Won't all users want to be able to gather their logs
using this command?

2 seems reasonable. It seems like we should restrict the file names if we
are going to have this limitation.

-Dan

On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao  wrote:

> Hello community,
>
> We are currently trying to improve what "export logs" should do. Currently
> export logs only export the logs(filtered by logLevel and start and end
> date) to each individual member's file system. We want to make all the
> member's logs exported to a central location  and if you are connecting
> using http, it will be exported to your local file system. This is to
> facilitate gathering logs in the cloud environment.
>
> That said, for the first round of implementation, we would like to impose
> these restrictions to this command:
> 1) it will only look for the logs/stats in each members working directory
> only.
> 2) it will only look for files that ends with .log, .log.gz, .gfs or
> .gfs.gz.
>
> Background for 1): if you started your locator/server with "log-file" or
> "statistics-archive-file" with an absolute path, it will write these files
> to that location, but if you simply give it a relative path, the files will
> be written to the member's working directory. The reasoning behind 1) is
> that this command is mostly for those environment that you can't easily go
> to the member's filesystem to get logs, but if you have started your
> server/locator with an absolute path like "/var/logs", we are assuming you
> already know how to get the logs, thus this command to not mean much to
> you.
>
> For restriction 2), since logs and stats files roll over, it is much easier
> to find the target files with extensions rather than file name patterns. We
> could either do not allow you to start server/locator with other file name
> suffix or post a warning. We would need the community's input on this.
>
> Any feedback is appreciated.
>
> --
> Cheers
>
> Jinmei
>

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103572486
  
--- Diff: src/quickstart/cpp/CMakeLists.txt ---
@@ -26,16 +26,6 @@ elseif(UNIX)
 set(DYNAMIC_LIBRARY_PATH LD_LIBRARY_PATH=${NATIVECLIENT_DIR}/lib)
 endif()
 
--- End diff --

Perhaps I'm missing context?  I'm not sure what it means.


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[dgkimura]

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

https://github.com/apache/geode-native/pull/42#discussion_r103572486
  
--- Diff: src/quickstart/cpp/CMakeLists.txt ---
@@ -26,16 +26,6 @@ elseif(UNIX)
 set(DYNAMIC_LIBRARY_PATH LD_LIBRARY_PATH=${NATIVECLIENT_DIR}/lib)
 endif()
 
--- End diff --

Perhaps I'm missing context?  I'm not sure what it means.


---
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-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103572155
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -150,9 +149,6 @@ else
   "24")
 exname='PdxInstance'
   ;;
-  "25")
-exname='PdxAutoSerializer'
-  ;;
   "26")
--- End diff --

Done.


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103572140
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -69,7 +69,6 @@ else
 echo 22.PdxRemoteQuery
 echo 23.PdxSerializer
 echo 24.PdxInstance
-echo 25.PdxAutoSerializer
 echo 26.Quit
--- End diff --

Yes, thanks for catching.


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[dgkimura]

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

https://github.com/apache/geode-native/pull/42#discussion_r103572140
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -69,7 +69,6 @@ else
 echo 22.PdxRemoteQuery
 echo 23.PdxSerializer
 echo 24.PdxInstance
-echo 25.PdxAutoSerializer
 echo 26.Quit
--- End diff --

Yes, thanks for catching.


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

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[dgkimura]

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

https://github.com/apache/geode-native/pull/42#discussion_r103572155
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -150,9 +149,6 @@ else
   "24")
 exname='PdxInstance'
   ;;
-  "25")
-exname='PdxAutoSerializer'
-  ;;
   "26")
--- End diff --

Done.


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

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #487 was SUCCESSFUL (with 1679 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #487 was successful.
---
Scheduled
1681 tests in total.

https://build.spring.io/browse/SGF-NAG-487/





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Dan Smith]

> On Feb. 28, 2017, 10:21 p.m., Darrel Schneider wrote:
> > geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java,
> >  line 26
> > 
> >
> > I found it confusing PageEntry was DataSerializable. Usually we do not 
> > want our internal classes to use DataSerializable.
> > 
> > But it looks to me like this class is never serialized. Instead we 
> > directly call toData and fromData in the PageResults class.
> > 
> > So I think it would be better to make this a class that does not 
> > support serialization directly. Otherwise someone in the future may be 
> > tempted to pass an instance of this class to writeObject.
> > 
> > I could be wrong about this and it would be good to check with the 
> > serialization team to see what they think.

Sure - I just changed the class so it doesn't implement DataSerializable. Let 
me know what you think.


- Dan


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


On Feb. 28, 2017, 10:41 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57170/
> ---
> 
> (Updated Feb. 28, 2017, 10:41 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If values on the server are in serialized form, leave them that way and
> only deserialize the values on the clients.
> 
> This is implemented by having the LuceneGetPageFunction extract the
> serialized value and return the results in a new PageResults class,
> which handles the deserialization and upwrapping of the value if
> necessary.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java
>  4e45646cf8aba6a66ed77514d270ffadd74d9859 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
>  f5c2b99e5bcb58997e973bc660c11c3925711bd0 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
>  9264126b0bc6cdd63f702c5628346516e3979792 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
>  c62082cbd54be3719530d1f5ccb5dbb653c280e1 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/57170/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Dan Smith]

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

(Updated Feb. 28, 2017, 10:41 p.m.)


Review request for geode, Barry Oglesby and Jason Huynh.


Changes
---

Removing DataSerializable from PageEntry, so that no one tries to serialize 
PageEntry directly.


Repository: geode


Description
---

If values on the server are in serialized form, leave them that way and
only deserialize the values on the clients.

This is implemented by having the LuceneGetPageFunction extract the
serialized value and return the results in a new PageResults class,
which handles the deserialization and upwrapping of the value if
necessary.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java 
4e45646cf8aba6a66ed77514d270ffadd74d9859 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
 dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
 f5c2b99e5bcb58997e973bc660c11c3925711bd0 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
 9264126b0bc6cdd63f702c5628346516e3979792 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
 PRE-CREATION 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
 c62082cbd54be3719530d1f5ccb5dbb653c280e1 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
 PRE-CREATION 

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


Testing
---


Thanks,

Dan Smith

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103568625
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -150,9 +149,6 @@ else
   "24")
 exname='PdxInstance'
   ;;
-  "25")
-exname='PdxAutoSerializer'
-  ;;
   "26")
--- End diff --

see above


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103568564
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -69,7 +69,6 @@ else
 echo 22.PdxRemoteQuery
 echo 23.PdxSerializer
 echo 24.PdxInstance
-echo 25.PdxAutoSerializer
 echo 26.Quit
--- End diff --

can we make Quit n-1?


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/42#discussion_r103568625
  
--- Diff: src/quickstart/runcpp.sh.in ---
@@ -150,9 +149,6 @@ else
   "24")
 exname='PdxInstance'
   ;;
-  "25")
-exname='PdxAutoSerializer'
-  ;;
   "26")
--- End diff --

see above


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

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[echobravopapa]

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

https://github.com/apache/geode-native/pull/42#discussion_r103569428
  
--- Diff: src/quickstart/cpp/CMakeLists.txt ---
@@ -26,16 +26,6 @@ elseif(UNIX)
 set(DYNAMIC_LIBRARY_PATH LD_LIBRARY_PATH=${NATIVECLIENT_DIR}/lib)
 endif()
 
--- End diff --

what I did locally to be able to build the quickstarts.


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

[GitHub] geode issue #397: Add junit to try parsing of simple XML file w pool ...

[oshvarts]

Github user oshvarts commented on the issue:

https://github.com/apache/geode/pull/397
  
fixed wildcards and spotless issue; hopefully fixed the unrelated test 
failure, though Travis does not seem to be running builds for me to test.


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

Re: Review Request 57171: GEODE-2461: remove json4s-ast_2.10 as explicit dependency

[Anthony Baker]

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


Ship it!




I think this was originally added due to swagger.  Once we moved to the new 
swagger2 approach this shouldn't be needed.

- Anthony Baker


On Feb. 28, 2017, 10:17 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57171/
> ---
> 
> (Updated Feb. 28, 2017, 10:17 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Jinmei Liao, Jared Stewart, Mark 
> Bretl, Udo Kohlmeyer, and Dan Smith.
> 
> 
> Bugs: GEODE-2461
> https://issues.apache.org/jira/browse/GEODE-2461
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove explicit dependency on json4s-ast_2.10.
> 
> I couldn't find anything that actually uses json4s-ast_2.10, directly or 
> transitively, so I've removed it completely.
> 
> 
> Diffs
> -
> 
>   geode-assembly/src/test/resources/expected_jars.txt 
> a9a5a792a4e4aafb9b191cd3bf89d54fe559bc75 
>   geode-web-api/build.gradle 8b22bd8de174ddad47f4acbd0da75614a060da99 
>   gradle/dependency-versions.properties 
> be828af14826ff63adee18717de063d87e2f1c6c 
> 
> Diff: https://reviews.apache.org/r/57171/diff/
> 
> 
> Testing
> ---
> 
> precheckin passed
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Darrel Schneider]

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




geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
 (line 26)


I found it confusing PageEntry was DataSerializable. Usually we do not want 
our internal classes to use DataSerializable.

But it looks to me like this class is never serialized. Instead we directly 
call toData and fromData in the PageResults class.

So I think it would be better to make this a class that does not support 
serialization directly. Otherwise someone in the future may be tempted to pass 
an instance of this class to writeObject.

I could be wrong about this and it would be good to check with the 
serialization team to see what they think.


- Darrel Schneider


On Feb. 28, 2017, 1:47 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57170/
> ---
> 
> (Updated Feb. 28, 2017, 1:47 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If values on the server are in serialized form, leave them that way and
> only deserialize the values on the clients.
> 
> This is implemented by having the LuceneGetPageFunction extract the
> serialized value and return the results in a new PageResults class,
> which handles the deserialization and upwrapping of the value if
> necessary.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java
>  4e45646cf8aba6a66ed77514d270ffadd74d9859 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
>  f5c2b99e5bcb58997e973bc660c11c3925711bd0 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
>  9264126b0bc6cdd63f702c5628346516e3979792 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
>  c62082cbd54be3719530d1f5ccb5dbb653c280e1 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/57170/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[jira] [Commented] (GEODE-2460) Update dependency versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2460:


Commit bc32a76c223d7a2b407fed72595af4056a78e433 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc32a76 ]

GEODE-2460: update dependency versions

* com.fasterxml.jackson.core:jackson-annotation:2.8.6
* com.fasterxml.jackson.core:jackson-core:2.8.6
* com.fasterxml.jackson.core:jackson-databind:2.8.6
* com.fasterxml.jackson.module:jackson-module-scala_2.10:2.8.6
* org.eclipse.persistence:javax.persistence:2.1.1
* fix dependency versions in NOTICE files


> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode-native/pull/42#discussion_r103564551
  
--- Diff: src/tests/cli/NewFwkLib/NewFwkLib.csproj.in ---
@@ -272,9 +272,6 @@
 
   SmokePerf\NoopAuthInit.cs
 
-
-  PdxTest\PdxAutoSerializerObj.cs
--- End diff --

Hmm.. besides the mistake that this referenced file isn't in the 
pull-request, I'm not sure this can go so easily.


> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[dgkimura]

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

https://github.com/apache/geode-native/pull/42#discussion_r103564551
  
--- Diff: src/tests/cli/NewFwkLib/NewFwkLib.csproj.in ---
@@ -272,9 +272,6 @@
 
   SmokePerf\NoopAuthInit.cs
 
-
-  PdxTest\PdxAutoSerializerObj.cs
--- End diff --

Hmm.. besides the mistake that this referenced file isn't in the 
pull-request, I'm not sure this can go so easily.


---
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-2441) Remove PDXAutoSerializer

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dgkimura opened a pull request:

https://github.com/apache/geode-native/pull/42

GEODE-2441: Remove leftover pdx auto serializer references

Remove leftover references from previous commits under GEODE-2441.  After 
this pull-request there are no references returned from grep in src directory.

`$ grep -n -R -i pdxautoserializer *`

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

$ git pull https://github.com/dgkimura/geode-native feature/GEODE-2441

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

https://github.com/apache/geode-native/pull/42.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 #42






> Remove PDXAutoSerializer 
> -
>
> Key: GEODE-2441
> URL: https://issues.apache.org/jira/browse/GEODE-2441
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Remove PDXAutoSerializer utility that generates PDX serialization C++ source 
> that you can include in your project to (de)serialize your C++ classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #42: GEODE-2441: Remove leftover pdx auto serializ...

[dgkimura]

GitHub user dgkimura opened a pull request:

https://github.com/apache/geode-native/pull/42

GEODE-2441: Remove leftover pdx auto serializer references

Remove leftover references from previous commits under GEODE-2441.  After 
this pull-request there are no references returned from grep in src directory.

`$ grep -n -R -i pdxautoserializer *`

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

$ git pull https://github.com/dgkimura/geode-native feature/GEODE-2441

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

https://github.com/apache/geode-native/pull/42.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 #42






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

Review Request 57170: GEODE-2538: Don't deserialize values on the server when getting results

[Dan Smith]

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

Review request for geode, Barry Oglesby and Jason Huynh.


Repository: geode


Description
---

If values on the server are in serialized form, leave them that way and
only deserialize the values on the clients.

This is implemented by having the LuceneGetPageFunction extract the
serialized value and return the results in a new PageResults class,
which handles the deserialization and upwrapping of the value if
necessary.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/DataSerializableFixedID.java 
4e45646cf8aba6a66ed77514d270ffadd74d9859 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
 dd32000c9cbb2525f2bb6edd1744c95cbfbaded3 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunction.java
 f5c2b99e5bcb58997e973bc660c11c3925711bd0 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/MapResultCollector.java
 9264126b0bc6cdd63f702c5628346516e3979792 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageEntry.java
 PRE-CREATION 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/results/PageResults.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/LuceneGetPageFunctionJUnitTest.java
 c62082cbd54be3719530d1f5ccb5dbb653c280e1 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageEntryJUnitTest.java
 PRE-CREATION 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/results/PageResultsJUnitTest.java
 PRE-CREATION 

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


Testing
---


Thanks,

Dan Smith

Re: [DISCUSS] changes to Redis implementation

[Bruce Schuchardt]

Yes, it looks like the Redis server is only labeled an Experimental 
Feature in the Pivotal docs for GemFire.  Geode docs don't label it 
experimental and no-one added @Experimental when that annotation was 
introduced.



Le 2/27/2017 à 1:40 PM, Dan Smith a écrit :

Given that the feature is still labeled experimental, do our backwards
compatibility constraints apply?


Actually, it doesn't look like it is marked with @Experimental or is
described as experimental in the docs.

That said, I think maybe it *should* have been marked as experimental
because I don't think it's completely baked or in common use. I'm not sure
how we want to deal with that. I'm generally in favor of switching this
model for storing hashes and sets, because I think that's the more common
use case. Maybe we just need to document that 1.2 breaks the upgrade from
1.1 for redis data?

-Dan

Re: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Mark Bretl]

There is an AWS outage right now, not sure if that is affecting the Gradle
plugin site...

--Mark

On Tue, Feb 28, 2017 at 10:53 AM, Bruce Schuchardt 
wrote:

> I deleted my gradle cache & am also having trouble downloading things
>
>:buildSrc:build UP-TO-DATE
>
>FAILURE: Build failed with an exception.
>
>* What went wrong:
>A problem occurred configuring root project 'geode'.
> > Could not resolve all dependencies for configuration ':classpath'.
>> Could not resolve
>gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
>  Required by:
>  :geode:unspecified
>   > Could not resolve
>gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
>  > Could not get resource
>'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> > Could not GET
>'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/a
> pache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
>Received status code 503 from server: Service Unavailable
>etc.
>
> I'm getting 503s on everything but the initial gradle download.
>
>
> Le 2/28/2017 à 10:40 AM, Avinash Dongre a écrit :
>
>> I am getting following error while running precheckin.
>>
>> * Where:
>> Build file '/home/ampool/private/geode/java/geode/geode-old-versions/bu
>> ild.gradle'
>> line: 58
>>
>> * What went wrong:
>> Execution failed for task ':geode-old-versions:createGeo
>> deClasspathsFile'.
>>
>>> Could not resolve all dependencies for configuration
>>> ':geode-old-versions:
>>>
>> test110Runtime'.
>> > Could not download geode-cq.jar (org.apache.geode:geode-cq:1.1.0)
>>> Could not get resource 'https://repo1.maven.org/
>> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'.
>>   > Could not GET 'https://repo1.maven.org/
>> maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'. Received
>> status
>> code 503 from server: Connection timed out
>>
>>
>>
>> On Tue, Feb 28, 2017 at 11:06 PM, Avinash Dongre 
>> wrote:
>>
>> It is my mistake.
>>>
>>> I will revert back my changes for this Test and raise a PR.
>>>
>>> Thanks
>>> Avinash
>>>
>>>
>>> On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt <
>>> bschucha...@pivotal.io
>>>
 wrote:
 ClientServerMiscBCDUnitTest is failing due to adongre's commit
 yesterday.  A parameterized test was added to a superclass, causing
 conflict with the subclass's parameterization of all the superclass's
 methods


 java.lang.Exception: Method testProxyRegionClientServerOp should have no
 parameters

  at org.junit.runners.model.FrameworkMethod.validatePublicVoidNo
 Arg(FrameworkMethod.java:76)
  at org.junit.runners.ParentRunner.validatePublicVoidNoArgMethod
 s(ParentRunner.java:155)
  at org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods
 (BlockJUnit4ClassRunner.java:208)
  at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMet
 hods(BlockJUnit4ClassRunner.java:188)
  at org.junit.runners.BlockJUnit4ClassRunner.collectInitializati
 onErrors(BlockJUnit4ClassRunner.java:128)
  at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
  at org.junit.runners.ParentRunner.(ParentRunner.java:84)
  at org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4C
 lassRunner.java:65)
  at org.junit.runners.parameterized.BlockJUnit4ClassRunnerWithPa
 rameters.(BlockJUnit4ClassRunnerWithParameters.java:27)
  at org.apache.geode.test.junit.runners.CategoryWithParameterize
 dRunner.(CategoryWithParameterizedRunner.java:29)
  at org.apache.geode.test.junit.runners.CategoryWithParameterize
 dRunnerFactory.createRunnerForTestWithParameters(CategoryWit
 hParameterizedRunnerFactory.java:40)
  at org.junit.runners.Parameterized.createRunnersForParameters(P
 arameterized.java:313)
  at org.junit.runners.Parameterized.(Parameterized.java:248)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
 ConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
 legatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
  at org.junit.internal.builders.AnnotatedBuilder.buildRunner(Ann
 otatedBuilder.java:104)
  at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(
 AnnotatedBuilder.java:86)
  at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(Run
 nerBuilder.java:59)
  at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.r
 unnerForClass(AllDefaultPossibilitiesBuilder.java:26)
  at 

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/41
  
+1
LGTM


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native issue #41: GEODE-2513 Rebrand Setting System Properties section

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/41
  
+1
LGTM


---
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-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/41

GEODE-2513 Rebrand Setting System Properties section

of Geode Native documentation

- Removed references to Pivotal GemFire and related commercial products
- Changed 'native client' to 'client.'
- Cosmetic wording changes

@davebarnes97 @joeymcallister   Can you please review these changes?

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-2

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

https://github.com/apache/geode-native/pull/41.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 #41






> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #41: GEODE-2513 Rebrand Setting System Properties ...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-native/pull/41

GEODE-2513 Rebrand Setting System Properties section

of Geode Native documentation

- Removed references to Pivotal GemFire and related commercial products
- Changed 'native client' to 'client.'
- Cosmetic wording changes

@davebarnes97 @joeymcallister   Can you please review these changes?

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-2

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

https://github.com/apache/geode-native/pull/41.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 #41






---
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: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Bruce Schuchardt]

I deleted my gradle cache & am also having trouble downloading things

   :buildSrc:build UP-TO-DATE

   FAILURE: Build failed with an exception.

   * What went wrong:
   A problem occurred configuring root project 'geode'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Could not resolve
   gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
 Required by:
 :geode:unspecified
  > Could not resolve
   gradle.plugin.org.nosphere.apache:creadur-rat-gradle:0.2.0.
 > Could not get resource
   
'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/apache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
> Could not GET
   
'https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/apache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.pom'.
   Received status code 503 from server: Service Unavailable
   etc.

I'm getting 503s on everything but the initial gradle download.

Le 2/28/2017 à 10:40 AM, Avinash Dongre a écrit :

I am getting following error while running precheckin.

* Where:
Build file 
'/home/ampool/private/geode/java/geode/geode-old-versions/build.gradle'
line: 58

* What went wrong:
Execution failed for task ':geode-old-versions:createGeodeClasspathsFile'.

Could not resolve all dependencies for configuration ':geode-old-versions:

test110Runtime'.
> Could not download geode-cq.jar (org.apache.geode:geode-cq:1.1.0)
   > Could not get resource 'https://repo1.maven.org/
maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'.
  > Could not GET 'https://repo1.maven.org/
maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'. Received status
code 503 from server: Connection timed out



On Tue, Feb 28, 2017 at 11:06 PM, Avinash Dongre  wrote:


It is my mistake.

I will revert back my changes for this Test and raise a PR.

Thanks
Avinash


On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt 

[jira] [Commented] (GEODE-2549) Remove unused sources

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/38


> Remove unused sources
> -
>
> Key: GEODE-2549
> URL: https://issues.apache.org/jira/browse/GEODE-2549
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> ACEDummy appears to be unused and may have been test code at some point.
> STLCompile appears to have been intended to force inclusion of STLPort 
> headers, which we don't use as of C++11.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #38: GEODE-2549: Delete unused files.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/38


---
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] [Updated] (GEODE-2404) Add API to destroy a region containing lucene indexes

[Karen Smoler Miller (JIRA)]

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

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

> Add API to destroy a region containing lucene indexes
> -
>
> Key: GEODE-2404
> URL: https://issues.apache.org/jira/browse/GEODE-2404
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: DestroyRegionMultipleMembersFunction.java
>
>
> h2. Description
> An application {{Region}} containing {{LuceneIndexes}} should be able to be 
> destroyed.
> There are several options, including:
> - Invoke one API to destroy both the application {{Region}} and its 
> {{LuceneIndexes}}
> - Invoke two API:
> ## destroy the {{LuceneIndexes}}
> ## destroy application {{Region}} as it is done currently
> h3. One API
> In this case, we would need a callback on {{LuceneService}} to destroy the 
> {{LuceneIndexes}} before destroying the application {{Region}} like:
> {noformat}
> public void beforeDestroyRegion(Region region);
> {noformat}
> This API would get all the {{LuceneIndexes}} for the application {{Region}}, 
> then destroy each one. See the *Two API* section below for details on 
> destroying a {{LuceneIndex}}.
> Without changes to the way {{PartitionedRegions}} are destroyed, this causes 
> an issue though.
> The current behavior of {{PartitionedRegion destroyRegion}} is to first check 
> for colocated children. If there are any, the call fails.
> There are two options for adding the call to destroy the {{LuceneIndexes}}:
> # check for colocated children
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # do the rest of the destroy
> 
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # check for colocated children
> # do the rest of the destroy
> Both of these options are problematic in different ways.
> In the case of a {{PartitionedRegion}} with {{LuceneIndexes}}, there are 
> colocated children, so the first option would cause the {{destroyRegion}} 
> call to fail; the second option would succeed. I don't think the first option 
> should fail since the colocated children are internal {{Regions}} that the 
> application knows nothing about.
> In the case of a {{PartitionedRegion}} defining {{LuceneIndexes}} and having 
> an {{AsyncEventQueue}}, there are colocated children, so the first option 
> would cause the {{destroyRegion}} call to fail. This is ok since one of the 
> children is an application-known {{AsyncEventQueue}}. The second option would 
> fail in a bad way. It would first remove the {{LuceneIndexes}}, then fail the 
> colocated children check, so the {{destroyRegion}} call would fail. In this 
> case, the application {{Region}} doesn't get destroyed but its 
> {{LuceneIndexes}} do. This would be bad.
> One option would be to look into changing the check for colocated children to 
> check for application-defined (or not hidden) colocated children. Then the 
> code would be something like:
> # check for application-defined colocated children
> # invoke LuceneService beforeDestroyRegion to remove the LuceneIndexes
> # do the rest of the destroy
> I think this would be ok in both cases.
> h3. Two API
> The destroy API on {{LuceneIndex}} would be something like:
> {noformat}
> public void destroy();
> {noformat}
> Destroying each {{LuceneIndex}} would require:
> # destroying the chunk {{Region}}
> # destroying the file {{Region}}
> # destroying the {{AsyncEventQueue}} which would require:
> ## retrieving and stopping the {{AsyncEventQueue's}} underlying 
> {{GatewaySender}} (there probably should be stop API on {{AsyncEventQueue}} 
> which does this)
> ## removing the id from the application {{Region's AsyncEventQueue}} ids
> ## destroying the {{AsyncEventQueue}} (this destroys the underlying 
> {{GatewaySender}} and removes it from the {{GemFireCacheImpl's}} collection 
> of {{GatewaySenders}})
> ## removing the {{AsyncEventQueue}} from the {{GemFireCacheImpl's}} 
> collection of {{AsyncEventQueues}} (this should be included in the destroy 
> method above)
> # removing {{LuceneIndex}} from {{LuceneService's}} map of indexes
> I also think the API on {{LuceneService}} should be something like:
> {noformat}
> public void destroyIndexes(String regionPath);
> public void destroyIndex(String indexName, String regionPath);
> {noformat}
> These methods would get the appropriate {{LuceneIndex(es)}} and invoke 
> destroy on them. Then they would remove the index(es) from the 
> {{LuceneService's}} collection of {{LuceneIndexes}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #32: GEODE-2439: Replace c-style headers with c++ ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/32


---
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: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Avinash Dongre]

I am getting following error while running precheckin.

* Where:
Build file 
'/home/ampool/private/geode/java/geode/geode-old-versions/build.gradle'
line: 58

* What went wrong:
Execution failed for task ':geode-old-versions:createGeodeClasspathsFile'.
> Could not resolve all dependencies for configuration ':geode-old-versions:
test110Runtime'.
   > Could not download geode-cq.jar (org.apache.geode:geode-cq:1.1.0)
  > Could not get resource 'https://repo1.maven.org/
maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'.
 > Could not GET 'https://repo1.maven.org/
maven2/org/apache/geode/geode-cq/1.1.0/geode-cq-1.1.0.jar'. Received status
code 503 from server: Connection timed out



On Tue, Feb 28, 2017 at 11:06 PM, Avinash Dongre  wrote:

> It is my mistake.
>
> I will revert back my changes for this Test and raise a PR.
>
> Thanks
> Avinash
>
>
> On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt  > wrote:
>
>> ClientServerMiscBCDUnitTest is failing due to adongre's commit
>> yesterday.  A parameterized test was added to a superclass, causing
>> conflict with the subclass's parameterization of all the superclass's
>> methods
>>
>>
>> java.lang.Exception: Method testProxyRegionClientServerOp should have no
>> parameters
>>
>> at org.junit.runners.model.FrameworkMethod.validatePublicVoidNo
>> Arg(FrameworkMethod.java:76)
>> at org.junit.runners.ParentRunner.validatePublicVoidNoArgMethod
>> s(ParentRunner.java:155)
>> at org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods
>> (BlockJUnit4ClassRunner.java:208)
>> at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMet
>> hods(BlockJUnit4ClassRunner.java:188)
>> at org.junit.runners.BlockJUnit4ClassRunner.collectInitializati
>> onErrors(BlockJUnit4ClassRunner.java:128)
>> at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
>> at org.junit.runners.ParentRunner.(ParentRunner.java:84)
>> at org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4C
>> lassRunner.java:65)
>> at org.junit.runners.parameterized.BlockJUnit4ClassRunnerWithPa
>> rameters.(BlockJUnit4ClassRunnerWithParameters.java:27)
>> at org.apache.geode.test.junit.runners.CategoryWithParameterize
>> dRunner.(CategoryWithParameterizedRunner.java:29)
>> at org.apache.geode.test.junit.runners.CategoryWithParameterize
>> dRunnerFactory.createRunnerForTestWithParameters(CategoryWit
>> hParameterizedRunnerFactory.java:40)
>> at org.junit.runners.Parameterized.createRunnersForParameters(P
>> arameterized.java:313)
>> at org.junit.runners.Parameterized.(Parameterized.java:248)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
>> ConstructorAccessorImpl.java:62)
>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(Ann
>> otatedBuilder.java:104)
>> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(
>> AnnotatedBuilder.java:86)
>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(Run
>> nerBuilder.java:59)
>> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.r
>> unnerForClass(AllDefaultPossibilitiesBuilder.java:26)
>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(Run
>> nerBuilder.java:59)
>> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequ
>> est.java:33)
>> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs
>> (JUnit4IdeaTestRunner.java:49)
>> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.star
>> tRunnerWithArgs(IdeaTestRunner.java:51)
>> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsA
>> ndStart(JUnitStarter.java:237)
>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStart
>> er.java:70)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at com.intellij.rt.execution.application.AppMain.main(AppMain.j
>> ava:147)
>>
>> here is the commit:
>>
>> commit f2721dc81256bcec84e855e9dc52d2f234e745da
>> Author: adongre  
>> Date:   Sat Feb 4 21:34:37 2017 +0530
>>
>> GEODE-1887: Now Size api goes through ServerProxy when cache is of
>> type client and DataPolicy is Empty.
>> Added a test for both PR and Replicated regions.
>>
>> GEODE-1887: Addressing review comments, refactor test based on the
>> region type.
>>
>> GEODE-1887: Spotless fixes.
>>
>> GEODE-1887: Addressing Review Comments.
>>

Errored: apache/geode#2121 (develop - 5ec0d47)

[Travis CI]

Build Update for apache/geode
-

Build: #2121
Status: Errored

Duration: 11 minutes and 44 seconds
Commit: 5ec0d47 (develop)
Author: adongre
Message: GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory, 
ReliableMessageQueueFactoryImpl and
it's usage in the code from GemfireCacheImpl and DistributedRegion.

GEODE-1995: Addressing Review Comments.
  Removed ReliableDistributionData
  CacheOperationMessage does not required now to implement 
ReliableDistributionData, as it is removed
  Removed all reference of getOperations and getOperationCount
  AbstractRegion#handleReliableDistribution does not use 
ReliableDistributionData removed the same.
  Removed SendQueueOperation
  Removed sendQueue from DistributedRegion
  Cleanup LocalizedStrings
  Removed SEND_QUEUE_MESSAGE from DataSerializableFixedID and DSFIDFactory

View the changeset: 
https://github.com/apache/geode/compare/b5fd6b50b18c...5ec0d470f25e

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/206093192

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[jira] [Commented] (GEODE-2549) Remove unused sources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2549:


Commit 5fd242c3c9258f0ffc58f95d94472d6bb3d2dfc5 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=5fd242c ]

GEODE-2549: Delete unused files.


> Remove unused sources
> -
>
> Key: GEODE-2549
> URL: https://issues.apache.org/jira/browse/GEODE-2549
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> ACEDummy appears to be unused and may have been test code at some point.
> STLCompile appears to have been intended to force inclusion of STLPort 
> headers, which we don't use as of C++11.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2439) Replace all non-standard types in all public includes / API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2439:


Commit 95b50641653f1249a52208dbc1ae5da33199ed23 in geode-native's branch 
refs/heads/develop from [~dkimura]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=95b5064 ]

GEODE-2439: Replace c-style headers with c++ headers

This closes #32.


> Replace all non-standard types in all public includes / API
> ---
>
> Key: GEODE-2439
> URL: https://issues.apache.org/jira/browse/GEODE-2439
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> research other non-standard types in API, ACE_Time



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Avinash Dongre]

It is my mistake.

I will revert back my changes for this Test and raise a PR.

Thanks
Avinash


On Tue, Feb 28, 2017 at 10:26 PM, Bruce Schuchardt 
wrote:

> ClientServerMiscBCDUnitTest is failing due to adongre's commit yesterday.
> A parameterized test was added to a superclass, causing conflict with the
> subclass's parameterization of all the superclass's methods
>
>
> java.lang.Exception: Method testProxyRegionClientServerOp should have no
> parameters
>
> at org.junit.runners.model.FrameworkMethod.validatePublicVoidNo
> Arg(FrameworkMethod.java:76)
> at org.junit.runners.ParentRunner.validatePublicVoidNoArgMethod
> s(ParentRunner.java:155)
> at org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods
> (BlockJUnit4ClassRunner.java:208)
> at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMet
> hods(BlockJUnit4ClassRunner.java:188)
> at org.junit.runners.BlockJUnit4ClassRunner.collectInitializati
> onErrors(BlockJUnit4ClassRunner.java:128)
> at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
> at org.junit.runners.ParentRunner.(ParentRunner.java:84)
> at org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4C
> lassRunner.java:65)
> at org.junit.runners.parameterized.BlockJUnit4ClassRunnerWithPa
> rameters.(BlockJUnit4ClassRunnerWithParameters.java:27)
> at org.apache.geode.test.junit.runners.CategoryWithParameterize
> dRunner.(CategoryWithParameterizedRunner.java:29)
> at org.apache.geode.test.junit.runners.CategoryWithParameterize
> dRunnerFactory.createRunnerForTestWithParameters(CategoryWit
> hParameterizedRunnerFactory.java:40)
> at org.junit.runners.Parameterized.createRunnersForParameters(P
> arameterized.java:313)
> at org.junit.runners.Parameterized.(Parameterized.java:248)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
> ConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
> legatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(Ann
> otatedBuilder.java:104)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(
> AnnotatedBuilder.java:86)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(Run
> nerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.
> runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(Run
> nerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequ
> est.java:33)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs
> (JUnit4IdeaTestRunner.java:49)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.star
> tRunnerWithArgs(IdeaTestRunner.java:51)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsA
> ndStart(JUnitStarter.java:237)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStart
> er.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.
> java:147)
>
> here is the commit:
>
> commit f2721dc81256bcec84e855e9dc52d2f234e745da
> Author: adongre  
> Date:   Sat Feb 4 21:34:37 2017 +0530
>
> GEODE-1887: Now Size api goes through ServerProxy when cache is of
> type client and DataPolicy is Empty.
> Added a test for both PR and Replicated regions.
>
> GEODE-1887: Addressing review comments, refactor test based on the
> region type.
>
> GEODE-1887: Spotless fixes.
>
> GEODE-1887: Addressing Review Comments.
>
> GEODE-1887: Spotless
>
>
>
>
> Le 2/28/2017 à 8:35 AM, Apache Jenkins Server a écrit :
>
> See 
> 
>  
> 
>
> Changes:
>
> [adongre] GEODE-2428: Adding support of Serialization/deserialization of
>
> [adongre] GEODE-1887: Now Size api goes through ServerProxy when cache is of 
> type
>
> [ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
> information
>
> [ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
> information
>
> [ukohlmeyer] GEODE-2142: Adding JSON library from the
>
> [ukohlmeyer] GEODE-2142: Amending JSONObject.java with cyclicalDependency 
> management
>
> [ukohlmeyer] GEODE-2142: Refactoring of tests to work with new JSONObject 
> class.
>
> [ukohlmeyer] 

Re: Review Request 57064: GEODE-2460: update dependency versions

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Feb. 28, 2017, 12:03 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57064/
> ---
> 
> (Updated Feb. 28, 2017, 12:03 a.m.)
> 
> 
> Review request for geode, Anthony Baker, Jared Stewart, Mark Bretl, Udo 
> Kohlmeyer, and Dan Smith.
> 
> 
> Bugs: GEODE-2460
> https://issues.apache.org/jira/browse/GEODE-2460
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2460: update dependency versions
> 
> * com.fasterxml.jackson.core:jackson-annotation:2.8.6
> * com.fasterxml.jackson.core:jackson-core:2.8.6
> * com.fasterxml.jackson.core:jackson-databind:2.8.6
> * com.fasterxml.jackson.module:jackson-module-scala_2.10:2.8.6
> * org.eclipse.persistence:javax.persistence:2.1.1
> * fix dependency versions in NOTICE files
> 
> 
> Diffs
> -
> 
>   geode-assembly/src/main/dist/NOTICE 
> 2cdda713bcb7d1ba5c09407f658273515dd63b8c 
>   geode-pulse/src/main/webapp/META-INF/NOTICE 
> 166a9ee94d0a0cdd41a4266fe3c042d4a1155624 
>   geode-web-api/src/main/webapp/META-INF/NOTICE 
> 8e1775bbcde41b909c817b68ac2eca05d4626c44 
>   gradle/dependency-versions.properties 
> be828af14826ff63adee18717de063d87e2f1c6c 
> 
> Diff: https://reviews.apache.org/r/57064/diff/
> 
> 
> Testing
> ---
> 
> precheckin passed (100% green)
> 2nd precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Build failed in Jenkins: Geode-nightly #762 - adongre, please read

[Bruce Schuchardt]

ClientServerMiscBCDUnitTest is failing due to adongre's commit 
yesterday.  A parameterized test was added to a superclass, causing 
conflict with the subclass's parameterization of all the superclass's 
methods



   java.lang.Exception: Method testProxyRegionClientServerOp should
   have no parameters

at
   
org.junit.runners.model.FrameworkMethod.validatePublicVoidNoArg(FrameworkMethod.java:76)
at
   
org.junit.runners.ParentRunner.validatePublicVoidNoArgMethods(ParentRunner.java:155)
at
   
org.junit.runners.BlockJUnit4ClassRunner.validateTestMethods(BlockJUnit4ClassRunner.java:208)
at
   
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:188)
at
   
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:128)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:416)
at org.junit.runners.ParentRunner.(ParentRunner.java:84)
at
   
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:65)
at
   
org.junit.runners.parameterized.BlockJUnit4ClassRunnerWithParameters.(BlockJUnit4ClassRunnerWithParameters.java:27)
at
   
org.apache.geode.test.junit.runners.CategoryWithParameterizedRunner.(CategoryWithParameterizedRunner.java:29)
at
   
org.apache.geode.test.junit.runners.CategoryWithParameterizedRunnerFactory.createRunnerForTestWithParameters(CategoryWithParameterizedRunnerFactory.java:40)
at
   
org.junit.runners.Parameterized.createRunnersForParameters(Parameterized.java:313)
at org.junit.runners.Parameterized.(Parameterized.java:248)
at
   sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
   
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
   
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at
   
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at
   
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at
   
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at
   
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at
   
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at
   org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
at
   
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:49)
at
   
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at
   
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
at
   com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
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
   com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

here is the commit:

   commit f2721dc81256bcec84e855e9dc52d2f234e745da
   Author: adongre 
   Date:   Sat Feb 4 21:34:37 2017 +0530

GEODE-1887: Now Size api goes through ServerProxy when cache is
   of type client and DataPolicy is Empty.
Added a test for both PR and Replicated regions.

GEODE-1887: Addressing review comments, refactor test based on the
region type.

GEODE-1887: Spotless fixes.

GEODE-1887: Addressing Review Comments.

GEODE-1887: Spotless




Le 2/28/2017 à 8:35 AM, Apache Jenkins Server a écrit :

See 


Changes:

[adongre] GEODE-2428: Adding support of Serialization/deserialization of

[adongre] GEODE-1887: Now Size api goes through ServerProxy when cache is of 
type

[ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
information

[ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
information

[ukohlmeyer] GEODE-2142: Adding JSON library from the

[ukohlmeyer] GEODE-2142: Amending JSONObject.java with cyclicalDependency 
management

[ukohlmeyer] GEODE-2142: Refactoring of tests to work with new JSONObject class.

[ukohlmeyer] GEODE-2142: spotless

[ukohlmeyer] GEODE-2142: cyclical dependency in gradle build

[ukohlmeyer] GEODE-2142: final compiling build

[ukohlmeyer] GEODE-2142: removing tests so run precheckin

[ukohlmeyer] GEODE-2142: Removing JSON licence stuff from 

Re: Build failed in Jenkins: Geode-nightly #762

[Ken Howe]

I’m working on the NetstatDUnitTest failure. GEODE-2541

Ken

> On Feb 28, 2017, at 8:35 AM, Apache Jenkins Server 
>  wrote:
> 
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-core:flakyTest'.
>> There were failing tests. See the report at: 
>> file://>  
>> >
> 

[GitHub] geode pull request #404: Geode 2469

[hiteshk25]

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

https://github.com/apache/geode/pull/404#discussion_r103497182
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java ---
@@ -187,8 +217,26 @@ public boolean removeKey(ByteArrayWrapper key, 
RedisDataType type, boolean cance
   return this.stringsRegion.remove(key) != null;
 } else if (type == RedisDataType.REDIS_HLL) {
   return this.hLLRegion.remove(key) != null;
+} else if (type == RedisDataType.REDIS_LIST) {
+  return this.destroyRegion(key, type);
 } else {
-  return destroyRegion(key, type);
+
+
+  // Check hash
+  ByteArrayWrapper regionName = 
HashInterpreter.toRegionNameByteArray(key);
+  Region region = this.getRegion(regionName);
+  if (region != null) {
+region.remove(HashInterpreter.toEntryKey(key));
--- End diff --

Needs to return from here?


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

Build failed in Jenkins: Geode-nightly #762

[Apache Jenkins Server]

See 


Changes:

[adongre] GEODE-2428: Adding support of Serialization/deserialization of

[adongre] GEODE-1887: Now Size api goes through ServerProxy when cache is of 
type

[ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
information

[ukohlmeyer] GEODE-2142: Removal of offending JSON.ORG code and license 
information

[ukohlmeyer] GEODE-2142: Adding JSON library from the

[ukohlmeyer] GEODE-2142: Amending JSONObject.java with cyclicalDependency 
management

[ukohlmeyer] GEODE-2142: Refactoring of tests to work with new JSONObject class.

[ukohlmeyer] GEODE-2142: spotless

[ukohlmeyer] GEODE-2142: cyclical dependency in gradle build

[ukohlmeyer] GEODE-2142: final compiling build

[ukohlmeyer] GEODE-2142: removing tests so run precheckin

[ukohlmeyer] GEODE-2142: Removing JSON licence stuff from NOTICE files

[upthewaterspout] GEODE-2515: Disabling BaseLineAndCompareQueryPerfJUnitTest

[huynhja] GEODE-2545: NPE during lucene query execution when cache is closing or

[boglesby] GEODE-2404: Added support for destroying lucene indexes

[upthewaterspout] GEODE-2538: Don't invoke a cache loader when fetching values 
for a

--
[...truncated 111.31 KB...]
:geode-cq: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-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
: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-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests